1. Forum
  2. Usenet
  3. COMP.LANG.POSTSCRIPT

  • Revised idea for utf8show

    From David Newall@21:1/5 to All on Mon Jan 31 05:03:06 2022
    Hi All,

    Yes, requiring a modified font is ugly, but a map from UNICODE values to
    glyph names is absolutely required.

    Fonts don't have /uniXXXX aliases for all glyphs, nor do they reliably
    use the names in AdobeGlyphList (which, anyway, does not even cover all
    written languages).

    I think I've come up with an elegant solution. It allows you to specify
    the actual glyph names from fonts that you use, or use AdobeGlyphList if
    you think that will be sufficient (it probably won't be.)

    I would greatly value constructive criticism.

    Meet unicodefont:

    font array|dict unicodefont dict

    Prepare a dictionary derived from font, adding a UNICODE map based on
    array or dict. The result, after registering with definefont, will be
    suitable for use with the utf8show family of operators.

    If an array is passed, it must contain one element for each UNICODE
    value to be installed in the map. Each element is an array containing
    a UNICODE value followed by one or more glyph names. The first name
    found in the font is associated with the UNICODE value.

    If a dict is passed, it's keys must be glyph names and values must
    be UNICODE values.

    Although the standard AdobeGlyphList could be used, this is not
    recommended. Fonts often use names that are different to those in
    AdobeGlyphList, and also often include many glyphs which are not
    listed in it. Using AdobeGlyphList is likely to result in characters
    not being painted even though they present in the font.

    It is strongly recommended that your encoding array maps all names
    actually used by the font with UNICODE values. Fontforge
    (https://fontforge.org) can generate a map of a font's glyphs when
    saving in .otf or .ttf format with the "output glyph map" option
    enabled. This produces a .g2n file which can be processed by awk:
    BEGIN{print "<<"}
    /GLYPHID .*PSNAME .*UNICODE .*/{print "/"$4, "16#"$6}
    END{print ">>"}

    The original font is not modified. A new font named key is created.

    Here's an example:

    %!
    /Helvetica-Unicode /Helvetica findfont 20 scalefont AdobeGlyphList
    unicodefont setfont
    100 300 moveto <~=(Q2XDf'&.FDi;]J=KV=7P-UZJ=Q~> utf8show showpage

    Regards,

    David

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Newall@21:1/5 to David Newall on Mon Jan 31 15:54:11 2022
    On 31/1/22 5:03 am, David Newall wrote:
    Yes, requiring a modified font is ugly, but a map from UNICODE values to glyph names is absolutely required.


    Following up on my own post, I should mention alternative ideas that I
    have.

    First is to include the UnicodeEncoding map with the string when
    invoking utf8show:

    /MyUnicode AdobeGlyphList makeunicode def
    MyUnicode (UTF8 String) utf8show

    Second is to have a global map, akin to currentpoint:

    AdobeGlyphList makeunicode setunicode
    (UTF8 String) utf8show

    Are these ideas better or worse than what I previously discussed?

    Thanks,

    David

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From luser droog@21:1/5 to David Newall on Mon Jan 31 22:03:49 2022
    On Sunday, January 30, 2022 at 10:54:28 PM UTC-6, David Newall wrote:
    On 31/1/22 5:03 am, David Newall wrote:
    Yes, requiring a modified font is ugly, but a map from UNICODE values to glyph names is absolutely required.
    Following up on my own post, I should mention alternative ideas that I
    have.

    First is to include the UnicodeEncoding map with the string when
    invoking utf8show:

    /MyUnicode AdobeGlyphList makeunicode def
    MyUnicode (UTF8 String) utf8show

    Second is to have a global map, akin to currentpoint:

    AdobeGlyphList makeunicode setunicode
    (UTF8 String) utf8show

    Are these ideas better or worse than what I previously discussed?

    Thanks,

    David

    I think all of these would be fine, such as they are. But I see more
    potential with the first idea of wrapping up all the information in
    the font. It may be possible to wrap the functionality of the glyph
    lookup in the /BuildChar procedure and get the whole thing to
    work with show or cshow.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)