Right... that goes for a lot of the rarer unicode code points. Another thing to go wrong with the blocks is that they come out different heights. (And that's true of superscript numerals in Courier: an annoyance for displaying SI-units!)
That appalling IJX animation was not the point, it was just a simple vehicle for presenting fh (and hst). Any serious use of these would be in a pro app, where you had some control over the fonts used. Or you could write off the whole technique as a curio, just motivation for an interesting (?) J problem concerning fractions based on eighths. BTW I discovered that upgrading my Mac to OS 10.6 (rather than buying a new Mac!) left me with my existing (out-of-date) copies of the standard fonts, notably "Courier" and "Courier New". Once I downloaded fresh copies of those fonts, lots of missing unicode chars appeared. These fonts could only have been extended in the last year or two. On Tue, Jan 24, 2012 at 6:46 AM, Ric Sherlock <tikk...@gmail.com> wrote: > Note that as Brian's post implies this is to do with the font you are > using in your J session. Some fonts include more or less unicode > chars. If you were wanting to use these chars in an application you > would need to specify a font or fonts that you knew contained the > desired unicode chars. > > On Tue, Jan 24, 2012 at 11:08 AM, Raul Miller <rauldmil...@gmail.com> wrote: >> In my copy of j, only u: 16b2588 (a solid block) and u: 16b258c (a >> block occupying the left hand side of the character position) display >> reasonably. >> >> The others are hollow boxes. >> >> -- >> Raul >> >> On Mon, Jan 23, 2012 at 4:47 PM, Ian Clark <earthspo...@gmail.com> wrote: >>> Unicode has a set of characters for building a crude (horizontal) histogram: >>> >>> u: 16b2588 NB. U+2588 (9608) 1.0 >>> u: 16b2589 NB. U+2589 (9609) 0.875 >>> u: 16b258a NB. U+258a (9610) 0.75 >>> u: 16b258b NB. U+258b (9611) 0.625 >>> u: 16b258c NB. U+258c (9612) 0.5 >>> u: 16b258d NB. U+258d (9613) 0.375 >>> u: 16b258e NB. U+258e (9614) 0.25 >>> u: 16b258f NB. U+258f (9615) 0.125 >>> >>> They can be used to implement a progress bar, or embed little >>> histograms in tables of figures. >>> >>> Notice a curious thing: these code points divide the basic block >>> (U+2588) into *eights*, not tenths! Why? >>> >>> I imagine it's for ultra-efficient ASM to pick the part-block from the >>> (base-2) mantissa of a floating-point number. But how do you do it >>> ultra-efficiently in J? >>> >>> See my solution at: >>> http://www.jsoftware.com/jwiki/Essays/Unicode%20Histogram >>> This uses the verb: fh to pick the code-point for the final >>> part-block. But I don't believe for a moment it's the best solution. >>> Anyone got a quicker/slicker fh? >>> ---------------------------------------------------------------------- >>> For information about J forums see http://www.jsoftware.com/forums.htm >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
