From B_Jackowski at GUST.org.pl  Fri Mar  1 15:18:26 2013
From: B_Jackowski at GUST.org.pl (Boguslaw Jackowski)
Date: Fri, 1 Mar 2013 15:18:26 +0100
Subject: [metapost] testing mpost 1.790 under Windows and Linux
Message-ID: <Pine.LNX.4.61.1303011516230.28370@linux.bop.eps.gda.pl>


Dear Taco,

very many thanks for releasing the version 1.790 of MetaPost.

We have tested it with one of our fonts. The resaults
are nearly good. :)

In a `standard' math mode (low precision) we were able to compile
the whole fonts without problems, the results being identical
to the results produced by mpost 1.5*.

We have four remarks: a serious one and three minor ones.
Let's start with tha latter ones.

1. Minor remarks:

   (a) mpost 1.790 is noticeably slower under Windows than
       the previous, 1.503, version; under Linux i64, there
       is no measurable difference

   (b) even the most trivial program invoked without mem file name
       given explicitly loops generating (infinitely?) many of parethesises:

       This is MetaPost, version 1.790 (kpathsea version 6.1.1dev)  1 MAR 2013 14:47
       **zz.mp
       (plain.mp Preloading the plain mem file, version 0.63))))))))...

       Passing on the command line parameter --mem=mpost
       cures the problem (note that --mem=mpost.mp doesn't)

   (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)

2. Serious remark: the primitive operation `directiontime' does not work
with the double precision option switched on in some cases.

Namely, for coordinate values close to 0 and multi B\'ezier paths
the results can get unexpected. Below is a simple example of the misbehavior:

   path p[]; pair d;
   p1=(0,-50){right}..(50,0){up}..{left}(0,50);
   p2=fullcircle scaled 100;

   d:=(if scantokens(mpversion)>1.7: -1e-14 else: 0 fi ,250); % proper result
   show (directiontime d of p1), point (directiontime d of p1) of p1;
   show (directiontime d of p2), point (directiontime d of p2) of p2;

   d:=(if scantokens(mpversion)>1.7: 1e-14 else: 0 fi ,250); % improper result
   show (directiontime d of p1), point (directiontime d of p1) of p1;
   show (directiontime d of p2), point (directiontime d of p2) of p2;

   end.

The result (both for Linux and Windows) is:

   piotrs at piotrs:~/wrk/mpost$ mpost1790 --mem=mpost -math=double test-math.mp
   This is MetaPost, version 1.790 (kpathsea version 6.1.1dev)
   (mpost.mp (/usr/local/texlive/2012/texmf-dist/metapost/base/plain.mp
   Preloading the plain mem file, version 1.004)) (./test-math.mp

   >> 1
   >> (50,0)
   >> 0
   >> (50,0)

   >> 0
   >> (0,-50)
   >> 7
   >> (35.35533919930458,-35.35533919930458) )

In the previous version, the second group of printouts was of course 
the same is first one. We guess that there is somewhere an error
of +/-1 type, but we are not able to trace it deeper.

Cheers -- loking forward to hearing from you before long -- Jacko and Piotr

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Bogus\l{}aw Jackowski: B_Jackowski at GUST.ORG.PL
----------------------------------------------------------------
  Hofstadter's Law: It always takes longer than you expect, even
                    when you take into account Hofstadter's Law.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



From mskala at ansuz.sooke.bc.ca  Fri Mar  1 16:34:28 2013
From: mskala at ansuz.sooke.bc.ca (mskala at ansuz.sooke.bc.ca)
Date: Fri, 1 Mar 2013 09:34:28 -0600
Subject: [metapost] Glyph names in METATYPE1
In-Reply-To: <Pine.LNX.4.61.1303011516230.28370@linux.bop.eps.gda.pl>
References: <Pine.LNX.4.61.1303011516230.28370@linux.bop.eps.gda.pl>
Message-ID: <alpine.LNX.2.02.1303010852550.27103@kharasan.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/

From B_Jackowski at GUST.org.pl  Sat Mar  2 22:01:18 2013
From: B_Jackowski at GUST.org.pl (Boguslaw Jackowski)
Date: Sat, 2 Mar 2013 22:01:18 +0100
Subject: [metapost] Glyph names in METATYPE1
Message-ID: <Pine.LNX.4.61.1303022157220.5167@linux.bop.eps.gda.pl>


Hello, Everybody,

BJ&PS:
>   (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)

MS:
> Not to derail your discussion,

You're welcome!

As we wrote some time ago, we'd be more than happy if you could
derail a few more discussions personally at a BachoTeX meeting...

> 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.

Right.

Needless to say, we're aware of this probblem. Perhaps it was our
somewhat unfortunate decision to use both suffixes and strings to
denote glyphs, but in some situations suffixes are more convenient
(more handy in notation) while in some -- strings are better
(more universal).

MS:
> I think it might work to insert an underscore before every character,
> turning "uni4E00" into "_u_n_i_4_E_0_0".

We came to nearly the same conclusion, although slightly different
in details.

Metatype1 provides a macro `assign_name' that makes life a little bit
easier, although one may wonder if it is the best solution.

Assume that you have to declare (in Metatype1 lingo -- "to introduce")
a glyph of name `uni0400', whatever its meaning. You may use the following 
construction:

    standard_introduce("uni0_400"); assign_name _uni0_400("uni0400");

i.e., for the purposes of processing within Metapost, the name
(the suffix) uni0_400 can be used, while the name uni0400 will be
exported to a Type1 font.

In our fonts, we prefer to use meaningful glyph names (suffixes)
rather then names stuffed with underscores.

Actually, the converter from Type1 to Metatype1, pf2mt1, generates
statements of this form, although it inserts more underscores.
The algorithm for "sanitizing" the names (written, of course,
in AWK ) is fairly simple:

   function sanitize_name(n,  n0,r) {
     if (n in SANITIZED) return SANITIZED[n]
     else {
       n0=n
       gsub(/[\-\+]/,"!", n)
       gsub(/;/,"?", n) # weird: XP Arial (2001) contains something like this!
       while (match(n,/[0-9][0-9]/)) {
         r=r substr(n,1,RSTART) "_"; n=substr(n,RSTART+RLENGTH-1)
       }
       n=r n
       while (n in XANITIZED) n=n "~"; SANITIZED[n0]=n; XANITIZED[n]
       return n
     }
   }

where SANITIZED and XSANITIZED are auxiliary global tables (vocabularies).

As you rightly noted, periods should be actually treated like digits.
We trod onto this trap quite recently, because of names like `mu1.alt'
(str mu1.alt yields, obviously, "mu1alt"). We will try to fix this as
soon as possible (but not sooner).

So, the main difference between your approach and ours is that we
use less underscores (still, less underscores could be used, however,
at the price of the complicating of the sanitizing procedure).

Is our comment to your comment comprehensible or at least sufficcient? :-)

Cheers -- Jacko & Piotr

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Bogus\l{}aw Jackowski: B_Jackowski at GUST.ORG.PL
----------------------------------------------------------------
  Hofstadter's Law: It always takes longer than you expect, even
                    when you take into account Hofstadter's Law.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



From B_Jackowski at GUST.org.pl  Sat Mar  2 22:09:39 2013
From: B_Jackowski at GUST.org.pl (Boguslaw Jackowski)
Date: Sat, 2 Mar 2013 22:09:39 +0100
Subject: [metapost] what about allsuffixes operator?
Message-ID: <Pine.LNX.4.61.1303022201420.5167@linux.bop.eps.gda.pl>


Hello, again,

MS:
> Not to derail your discussion,

To derail the discussion further, we would like to come up
with a proposal (it sprouts in our heads quite a long time)
of extending the functionality of Metapost by an
`allsuffixes' operator.

Let's explain the idea on a trivial example. Assume that we have
declared or used variables a.a, a.a.b, a.a.b.c; then the statement
    forsuffixes $:=allsuffixes a:
would succesively assign to $ the suffixes a, a.b, a.b.c,
and the statement
    forsuffixes $:=allsuffixes a.a:
would succesively assign to $ the suffixes b, b.c.

Perhaps the operation of the undefining of a variable
(i.e., deleting it, not to be confused with the assigning
of an undefined value to a variable) should consequently
accompany such and extension.

The generated sequence of suffixes could be perhaps
lexicographically ordered.

Note that such an operation actually is ("implicitly")
implemented in Metafont, and, thus, in Metapost.
The primitive `showvariable' does the job, with lexicographic
sorting. (There is not, however, the `delete' operation.)

Alas, since mpost 1.5*, `showvariable' does not work any longer.
For example, the simple program:

     a1=2; a2=3; showvariable a;

produces the following log for mpost 1.2:

    a[]=numeric
    a1=2
    a2=3

while mpost 1.5 (and later) emits an enigmatic message:

   a=tag

Is there a chance that the behaviour of `showvariable' will
improve some nice day?

Cheers -- Jacko & Piotr

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Bogus\l{}aw Jackowski: B_Jackowski at GUST.ORG.PL
----------------------------------------------------------------
  Hofstadter's Law: It always takes longer than you expect, even
                    when you take into account Hofstadter's Law.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-