From: Debbie Garside (debbie@ictmarketing.co.uk)
Date: Fri Oct 03 2008 - 11:51:30 CDT
Mark wrote:
It sounds like what you're saying is that you want to
> be able, say, to instruct your program to stop in the middle
> of rendering an i, after drawing the body but before drawing
> the dot.
Yes.
> So you could, say, have seven different "i" glyphs, each with
> a different dot, and instructions to use *this* one when it's
> followed by a "j", but *that* one when it's in the word
> "minimum", and *the other* one when it appears by itself. Is
> that the kind of thing you're trying to get at?
Yes. Thanks
Debbie
> -----Original Message-----
> From: Mark E. Shoulson [mailto:mark@kli.org]
> Sent: 03 October 2008 17:30
> To: debbie@ictmarketing.co.uk
> Cc: 'Marion Gunn'; unicode@unicode.org
> Subject: Re: Pixel Rendering in Unicode characters
>
> Debbie Garside wrote:
>
> > Hi Marion
> >
> > Thanks for this. Yes I know about leading and kerning etc.
> but what
> > I really want to know is what programming is used within fonts to
> > start and stop printing within a glyph and is it a specific
> piece of
> > code that could be used within another application to say
> when you hit 'y' carry out 'x'
> > procedure.
> >
> >
>
> A glyph in a font consists of things like "OK, these points
> (specified by Cartesian coordinates, yes) specify a curve
> that's the boundary of one filled-in area... and here's
> another... and here's another..." A program *using* the font
> can't generally know which such area comes first, or how many
> there are, etc. After all, not all fonts have the same
> number of filled-in areas for a given letter. Sometimes i's
> aren't dotted. Sometimes (in "grunge" fonts) there are other
> specks and blobs of ink spattered around. A program on the
> outside, using the font (like say a word-processor, as
> opposed to one that's actually rendering it, like the
> low-level libraries for font-rendering) doesn't get to know
> much about the details of the letters: it just gets "boxes"
> so it knows how to stick them together to leave the right
> amount of space. There isn't even a guarantee that the box
> encloses all of the ink of the letter. Sometimes it's
> sensible to let parts of the letter protrude out of the box
> (where, yes, they might possibly interfere with other
> letters; that's where the "design" part of font-design comes
> in). It sounds like what you're saying is that you want to
> be able, say, to instruct your program to stop in the middle
> of rendering an i, after drawing the body but before drawing
> the dot. But you can't even know whether the font chooses to
> draw the body or the dot first! Most font-designers don't
> even know, because it doesn't matter. You can root through
> the details of the glyph to find out, but generally you don't
> care. And of course you don't know if there are other
> flourishes or blobs that are being drawn that are neither
> letter-body nor dot. You have to do this kind of thing
> inside the font, generally by redesigning or redrawing it.
>
> So you could, say, have seven different "i" glyphs, each with
> a different dot, and instructions to use *this* one when it's
> followed by a "j", but *that* one when it's in the word
> "minimum", and *the other* one when it appears by itself. Is
> that the kind of thing you're trying to get at?
>
> Oh, yeah, like everyone else said: this is also a font
> matter, and thus highly dependent on what kind of font is
> being used or designed (some systems can't do the things I'm
> talking about, etc), and not a Unicode matter. As you put it
> rather well: Unicode is the labeling system.
>
> ~mark
>
>
>
>
This archive was generated by hypermail 2.1.5 : Fri Oct 03 2008 - 11:53:25 CDT