[Top][All Lists]

[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

From: Hin-Tak Leung
Subject: Re: [cjk] New combo script - Re: The fixed-up script and the fixed Noto type 1 fonts.
Date: Tue, 4 Jul 2017 22:57:53 +0000 (UTC)

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

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 
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 
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, 
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 
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 
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 
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
 > python API -
 > https://github.com/HinTak/freetype-py/blob/fontval-diag/examples/subfonts.py
 Very nice!  Thanks for your
 > you just
 > fontforge
 -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
 This also
 belongs to the documentation.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]