Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #3743 > unrolled thread

Revised idea for utf8show

Back to article view | Back to comp.lang.postscript

Contents

  Revised idea for utf8show David Newall <davidn@davidnewall.com> - 2022-01-31 05:03 +1100
    Re: Revised idea for utf8show David Newall <davidn@davidnewall.com> - 2022-01-31 15:54 +1100
      Re: Revised idea for utf8show luser droog <luser.droog@gmail.com> - 2022-01-31 22:03 -0800

#3743 — Revised idea for utf8show

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

[toc] | [next] | [standalone]

#3744

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

[toc] | [prev] | [next] | [standalone]

#3745

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.postscript

csiph-web