Re: Pixel Rendering in Unicode characters

From: Christopher Fynn (cfynn@gmx.net)
Date: Tue Oct 07 2008 - 17:22:24 CDT

  • Next message: Richard Ishida: "Mongolian script samples"

    Debbie

    In an OpenType font you could easily substitute different forms of i (or
    i with different dots) depending on context.

    - chris

    Debbie Garside wrote:
    > 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?
    >
    > Ina
    > 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 : Tue Oct 07 2008 - 17:27:47 CDT