Re: [cjk] New combo script - Re: The fixed-up script and the fixed Noto type 1 fonts.

[Hin-Tak Leung]

(Thorsten: the below is mostly technical, and FYI. Don't worry if this is 
beyond comprehension...)

I have updated the documentation header with a lot more info now; have a look.
https://github.com/HinTak/freetype-py/blob/fontval-diag/examples/subfonts.py

The "Must move /usr/share/fontforge/Adobe-Identity-0.cidmap!" line was mostly 
just
a quick reminder to myself - I think that file's presence is a mistake and so I 
have moved
it; but I just upgraded to fedora 26 a few days ago ahead of GA, and the 
upgrade brought
that file back :-).

Except for the freetype-py stuff, it is largely a line-by-line translation of 
the older script.
So caveats below[1], you can use it wherever the old one is used, subjected to 
fontforge
being built with the python extension. I have sort of challenged Khaled Hosny 
to remove
the freetype-py dependency and to do it entirely within fontforge's python API, 
and
this is what he came up with:  
https://github.com/fontforge/fontforge/issues/3085#issuecomment-312756863
So I guess I could just give it 1/2 hour to just run it and see if his 
suggestions works.
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.

[1]   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 
interesting
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 
without-argument
behavior of AddExtrema() different - 
( https://github.com/fontforge/fontforge/issues/3105 ) - or maybe the 
documentation
is poor or I don't understand the documentation . I am showhat worried that I 
cannot
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 
font-unit(?) difference
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
 fontforge's
 > python API -
 > 
 > https://github.com/HinTak/freetype-py/blob/fontval-diag/examples/subfonts.py
 
 Very nice!  Thanks for your
 efforts.
 
 > you just
 do:
 > 
 > fontforge
 -script subfonts.py ...
 
 Please extend the documentation in the file
 header:
 
   . The `must
 move' sentence is not really comprehensible IMHO; I
     think a more extensive explanation is
 necessary.
 
   . A better
 description of the dependency on the `freetype-py'
 python
     package: where to download,
 which version to use, how to install,
    
 etc.
 
 I presume that this
 script is a generalization of the original
 `subfonts.pe', working with all CJK fonts,
 right?
 
 > as long as your fontforge
 is built with its python extensions. (most
 > linux builds are, not sure about
 windows).
 
 This also
 belongs to the documentation.
 
 
     Werner