Re: GSoC 2020 update, May 30

[Owen Lamb]

Hi Werner,

Thank you for pointing out the Metapost documentation!

I've given it a look, and I wonder whether using a number type to store the
codes is worth the hassle of conditionally changing the number system.
According to the docs, there is no 0x prefix or anything similar to denote
a numeric hexadecimal literal. It seems that, if we want to use hexadecimal
number representation in the metafont files (which I think would be ideal
for human readability) and store it internally as a number too, our only
choice is to call the hex function on a string, then call decimal on it
when printing it to the log file. This seems superfluous. Leaving the codes
as strings from the start would make concatenation into the log file more
straightforward and remove the need to quarantine everything
smuflcode-related from
everything else. And Python can parse a hex string as easily as it can
parse decimal strings, so reading the log won't be an issue on its end.

Would it be all right if I continued using strings for smuflcode, or would
you prefer I switch to a numeric representation?

--Owen

On Sat, May 30, 2020 at 11:49 PM Werner LEMBERG <wl@gnu.org> wrote:

>
> > I started work on Han-Wen's suggested order of operations. In order
> > to make the .mf files output a SMuFL code to their log, I needed to
> > learn Metafont, which proved to be a language as little documented
> > as it is ingenious.  [...]
>
> In case you have TeXLive installed, simply type
>
>   texdoc metapost
>
> to get a nice and short introduction into METAPOST (this is what we
> actually use to generate the fonts instead of METAFONT).
>
> > (I had to use strings because MF doesn't support numbers at/above
> > 4096.)
>
> This is not true for (recent versions of) METAPOST, which supports
> various number systems, including IEEE 64bit floating point.  However,
> to still allow processing with METAFONT to generate the nice DVI glyph
> previews, such code should be restricted so that it is executed for
> METAPOST only.  Note that selecting the number system is a run-time
> option (see appendix A); if you really need large integers, the build
> system of LilyPond has to be updated accordingly (and probably the
> minimum version of METAPOST, too).
>
> > As an aside, looking at my Git history, it appears that, when I
> > tried to change the name of my first commit to be more informative,
> > I accidentally fused it with Valentin's previous commit.  [...]
>
> Don't worry.  For GSoC purposes I strongly suggest that, shortly
> before the end, you create another branch that contains your stuff in
> concise, small, and logically ordered commits so that reviewers can
> easily follow.
>
>
>     Werner
>
>
> PS: A remark to Freetype versions: I think you can safely assume that
>     FreeType 2.6 and newer is available.  There is other code in
>     LilyPond that could be simplified if this assumption is true, and
>     I will eventually submit a Merge Request to handle that.
>