[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cjk] New combo script - Re: The fixed-up script and the fixed Noto
Re: [cjk] New combo script - Re: The fixed-up script and the fixed Noto type 1 fonts.
Tue, 4 Jul 2017 22:57:53 +0000 (UTC)
(Thorsten: the below is mostly technical, and FYI. Don't worry if this is
I have updated the documentation header with a lot more info now; have a look.
The "Must move /usr/share/fontforge/Adobe-Identity-0.cidmap!" line was mostly
a quick reminder to myself - I think that file's presence is a mistake and so I
it; but I just upgraded to fedora 26 a few days ago ahead of GA, and the
that file back :-).
Except for the freetype-py stuff, it is largely a line-by-line translation of
the older script.
So caveats below, you can use it wherever the old one is used, subjected to
being built with the python extension. I have sort of challenged Khaled Hosny
the freetype-py dependency and to do it entirely within fontforge's python API,
this is what he came up with:
So I guess I could just give it 1/2 hour to just run it and see if his
The worst case is simply wasting 1/2 hour of CPU time; I am not very hopeful it
will - after having seen the underlying C code of fontforge a bit - but maybe
it will surprise me. Let's see. Maybe freetype-py is not needed.
The freetype-py code is not very version-sensitive - so any should work.
 The script-to-generate-a-legacy-script approach, when runs on the Arphic
fonts, does nothing interesting (the 4 Arphic fonts simply don't have
glyphs with multiple encoding slots, or any - this was posted a while ago),
but when migrating the whole thing to python, I found the default
behavior of AddExtrema() different -
( https://github.com/fontforge/fontforge/issues/3105 ) - or maybe the
is poor or I don't understand the documentation . I am showhat worried that I
get identical results - except for some unimportant timestamps - moving
between the two script interfaces, when the underlying code seems identical
or nearly the same. In principle I can just run fontforge in gdb and breaks
at the same place to see what exactly fontforge is doing in the two situations,
but this is not easy in practice with such large fonts :-).
That said, the Source/Noto CJK fonts are sufficiently well-behaving that
AddExtrema() or Simplify()
are not particularly useful. So as long as AddExtrema() or Simplify() do not do
anything totally wrong, it is probably not important. I also see some 1
in the afm files also between the two approaches; I hope the diff in numbers
I saw are just bounding boxes - the advance width for CJK fonts should be
mostly boring the same.
On Tue, 4/7/17, Werner LEMBERG <address@hidden> wrote:
> I have
converted the fontforge native script stuff to
> python API -
Very nice! Thanks for your
> you just
-script subfonts.py ...
Please extend the documentation in the file
. The `must
move' sentence is not really comprehensible IMHO; I
think a more extensive explanation is
. A better
description of the dependency on the `freetype-py'
package: where to download,
which version to use, how to install,
I presume that this
script is a generalization of the original
`subfonts.pe', working with all CJK fonts,
> as long as your fontforge
is built with its python extensions. (most
> linux builds are, not sure about
belongs to the documentation.