[metapost] Glyph names in METATYPE1

[mskala at ansuz.sooke.bc.ca]

On Fri, 1 Mar 2013, Boguslaw Jackowski wrote:
>   (c) there is a (known) trouble with the syntax of numbers: a digit
>       followed by the letter 'e'... -- this is easy to circumvent
>       (but still annoying; we have a few formulas containing
>       <number>eps or <number>epsilon expressions in our mpost programs)

Not to derail your discussion, but this point reminds me of something I've
noticed about METATYPE1; it hasn't been a showstopping issue for me, but I
have found it necessary to work around it already, and the above point
looks like it may make my workaround more difficult.

In METATYPE1, the name specified as parameter to beginglyph() is scanned
into tokens and used as a suffix, even if specified as a string, and what
gets written into the Postscript file is those tokens translated back into
a string rather than the originally-specified string.  The most
significant consequence is that hexadecimal numbers don't survive the
round trip through the scanner.

For instance, I have a glyph that should be named "uni4E01" (it is a
Japanese character vaguely resembling a capital "T," and that name is
mandated by Adobe's glyph-naming standard) and when I specify that as the
argument to beginglyph(), the name in the Postscript file is "uni4E1"
because Metapost parses "01" into the integer one and then converts that
integer to the string "1".  If sequences of digits and the letter "E" will
be interpreted as scientific notation, I imagine that the same glyph might
end up named something like "uni40" because "4E01" will be read as the
integer forty, for which the canonical string representation is probably
"40".  Periods are also allowed and commonly occur in glyph names, and I
could easily imagine that there might be trouble distinguishing for
instance "1", "1.", and "1.0"; but in fact that hasn't been where I've had
trouble in my own project.

As long as each glyph is parsed as *some* valid sequence of tokens, and no
two names in the same file end up colliding after translation, it's not a
big deal for me:  I can rename the glyphs later.  But I certainly have
some glyph names that might look like invalid numeric values, and if they
cause the interpreter to die with an error, that'll be a problem.

I may be able to modify METATYPE1's macros to save the original string and
write that into the Postscript file.  However, there are also many places
where METATYPE1 uses the parsed glyph name as a suffix to identify
per-glyph data, so if there are glyph names that can't be validly parsed,
something more clever will have to be done than just saving a copy of the
unparsed string.  The simplest thing that occurs to me would be to extend
beginglyph() to take two separate parameters:  one for the string glyph
name to write to the Postscript file, and one for the suffix to use
internally (which the programmer promises will be validly parseable).  It
wouldn't be hard for me (probably just a one-line Perl script) to modify
my code that way and it may be the best thing for me to do in my own
project.  I don't know how acceptable a change in beginglyph()'s arguments
would be for other METATYPE1 users.  Another possibility might be for
beginglyph() to process the string in some way guaranteed to make it
parseable as a suffix without information loss - for instance, I think it
might work to insert an underscore before every character, turning
"uni4E00" into "_u_n_i_4_E_0_0".

I've also experienced a related issue when a glyph name when parsed into
tokens happened to contain a token that had a special meaning - for
instance, a glyph named "uni1100.l2" had to be changed to "uni1100.lj2"
(Korean hangul "kiyeok", lead jamo, layout number 2) because METATYPE1
wanted to parse the string in a context where it had defined "l" with
"def".  (Parsing and string translation subsequently removed the period
from the name.)

I'll experiment with it, but thought I should let you know about this as
something worth considering in future development of Metapost and
METATYPE1.
-- 
Matthew Skala
mskala at ansuz.sooke.bc.ca                 People before principles.
http://ansuz.sooke.bc.ca/