[Fontforge-users] The existing ligature stop working after embedding bitmap font in .ttf

[ffnewbie1]

I used the Element->Bitmap Strikes Available to create the bitmap strikes
and saved in the .ttf file with ligature. I hoped the the same ligature can
be applied to the bitmap font with the size that I created (just as kerning
worked successfully for me). But once I generated the new font in .ttf with
the embedded bitmap strikes, the ligature table got automatically changed,
and I was not able to get the expected substitution. I saved the feature
files before and after and compared them. They are two different files and
the feature file gen'd from the embedded bitmap ttf file contains much less
information than the original one. So the ligature is totally not working
for the newly gen'd .ttf, not for the bitmap or for the true type font.

I'm not sure why the GSUB lookup tables for ligature got changed after the
font generation. I would like to know if there is a way to reach my goal
--
Apply the existing ligature to the embedded bitmap .ttf file.

Thank you in advance for any help!

[Khaled Hosny]

Post by ffnewbie1
I used the Element->Bitmap Strikes Available to create the bitmap strikes
and saved in the .ttf file with ligature. I hoped the the same ligature can
be applied to the bitmap font with the size that I created (just as kerning
worked successfully for me). But once I generated the new font in .ttf with
the embedded bitmap strikes, the ligature table got automatically changed,
and I was not able to get the expected substitution. I saved the feature
files before and after and compared them. They are two different files and
the feature file gen'd from the embedded bitmap ttf file contains much less
information than the original one. So the ligature is totally not working
for the newly gen'd .ttf, not for the bitmap or for the true type font.
I'm not sure why the GSUB lookup tables for ligature got changed after the
font generation. I would like to know if there is a way to reach my goal

Some cosmetic information (like lookup names) are not saved to the TTF
file (the TTF structure does not have them, they are mainly cosmetic to
help FontForge users), upon opening the font FontForge will 'generate'
new names, so if that is the only difference it should be harmless, else
please show us the files to compare.

Regards,
Khaled

[ffnewbie1]

Post by Khaled Hosny
Some cosmetic information (like lookup names) are not saved to the TTF
file (the TTF structure does not have them, they are mainly cosmetic to
help FontForge users), upon opening the font FontForge will 'generate'
new names, so if that is the only difference it should be harmless, else
please show us the files to compare.
Regards,
Khaled

It's not only the name change.

I did some more tests and find out that it has nothing to do with the
embedded bitmap. Here is a simple test:

1) open a font file, say "before.ttf" with GSUB info in fontforge
2) select all the tables in Element->Font Info-> Lookups->GSUB tab, right
click, save feature file... into "before.fea"
3) in the same "before.ttf", File->Generate Fonts, to generate another
"after.ttf" using the same unchanged information from "before.ttf".
4) open "after.ttf" in fontforge, repeat step 2) to save a feature file for
"after.ttf" into "after.fea".

"before.fea" and "after.fea" are different, and the original ligature does
not work any more by using "after.ttf".

BTW, the before.ttf also contains GPOS tables, even I only selected tables
in the GSUB tab to save into feature file, I do see some kerning info in the
before.fea as well. But in after.ttf, GSUB tables get changed and no
tables shown up in GPOS tab.

How can I preserve the existing GSUB tables to apply to another font? Thank
you!


Here I uploaded the files for before.fea(good) and after.fea(bad).

http://old.nabble.com/file/p33081771/before.fea before.fea
http://old.nabble.com/file/p33081771/after.fea after.fea

[Khaled Hosny]

Post by ffnewbie1

Post by Khaled Hosny
Some cosmetic information (like lookup names) are not saved to the TTF
file (the TTF structure does not have them, they are mainly cosmetic to
help FontForge users), upon opening the font FontForge will 'generate'
new names, so if that is the only difference it should be harmless, else
please show us the files to compare.
Regards,
Khaled

It's not only the name change.
I did some more tests and find out that it has nothing to do with the
1) open a font file, say "before.ttf" with GSUB info in fontforge
2) select all the tables in Element->Font Info-> Lookups->GSUB tab, right
click, save feature file... into "before.fea"
3) in the same "before.ttf", File->Generate Fonts, to generate another
"after.ttf" using the same unchanged information from "before.ttf".
4) open "after.ttf" in fontforge, repeat step 2) to save a feature file for
"after.ttf" into "after.fea".
"before.fea" and "after.fea" are different, and the original ligature does
not work any more by using "after.ttf".
BTW, the before.ttf also contains GPOS tables, even I only selected tables
in the GSUB tab to save into feature file, I do see some kerning info in the
before.fea as well. But in after.ttf, GSUB tables get changed and no
tables shown up in GPOS tab.
How can I preserve the existing GSUB tables to apply to another font? Thank
you!
Here I uploaded the files for before.fea(good) and after.fea(bad).
http://old.nabble.com/file/p33081771/before.fea before.fea
http://old.nabble.com/file/p33081771/after.fea after.fea

Ho do you generate the font? What are the checked options in File ->
Generate Fonts -> Options?

Regards,
Khaled

[ffnewbie1]

Post by Khaled Hosny
Ho do you generate the font? What are the checked options in File ->
Generate Fonts -> Options?
Regards,
Khaled

I didn't specifically check or uncheck anything. Here're the boxes checked:

Postscript session:
Hints; Flex Hints

SFNT session:
True Type Hints; PS Glyph Names; Apple; Lookup Names


---------------------------------

To Matthew Skala:

Thank you for your reply. I did find some of the feature files generated
cannot be applied back. It gaves syntax error, which is really annoying.
Is it already raised as a bug? If not, where can user report this kind of
error? In general, Fontforge is a quite easy-to-use and powerful tool to
me. I'm still really new in this area...

[Khaled Hosny]

Post by ffnewbie1

Post by Khaled Hosny
Ho do you generate the font? What are the checked options in File ->
Generate Fonts -> Options?
Regards,
Khaled

Hints; Flex Hints
True Type Hints; PS Glyph Names; Apple; Lookup Names

^^^^^
That is what I expected, uncheck 'Apple' and check 'OpenType' instead.

Regards,
Khaled

[ffnewbie1]

Cool! It's working, it's working now!

Thanks a lot, Khaled!

Post by Khaled Hosny

Post by ffnewbie1

Post by Khaled Hosny
Ho do you generate the font? What are the checked options in File ->
Generate Fonts -> Options?
Regards,
Khaled

Hints; Flex Hints
True Type Hints; PS Glyph Names; Apple; Lookup Names

^^^^^
That is what I expected, uncheck 'Apple' and check 'OpenType' instead.
Regards,
Khaled
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Fontforge-users mailing list
https://lists.sourceforge.net/lists/listinfo/fontforge-users

[m***@ansuz.sooke.bc.ca]

Post by ffnewbie1
2) select all the tables in Element->Font Info-> Lookups->GSUB tab, right
click, save feature file... into "before.fea"

I have observed that feature files saved by FontForge are often simply
incorrect. They may not accurately reflect what is in the font; and
FontForge itself, let alone other implementations of the spec, may not be
able to load the feature files that FontForge saves. I suggest that
instead of comparing saved feature files, you inspect the actual contents
of the tables via Font Info; try the substitutions in the metrics window;
and test the substitutions in other software that understands such
substitutions. Beware, the GSUB implementation in the ICU layout engine,
used by XeTeX and some other systems, is incorrect and may produce the
wrong results on some complex GSUB tables even when the tables themselves
are correct. FontForge's implementation of GSUB substitution in the
metrics window appears to be correct, or at least not to have the same
major bug as ICU.

[ffnewbie1]

Post by m***@ansuz.sooke.bc.ca
I have observed that feature files saved by FontForge are often simply
incorrect. They may not accurately reflect what is in the font; and
FontForge itself, let alone other implementations of the spec, may not be
able to load the feature files that FontForge saves. I suggest that
instead of comparing saved feature files, you inspect the actual contents
of the tables via Font Info; try the substitutions in the metrics window;
and test the substitutions in other software that understands such
substitutions. Beware, the GSUB implementation in the ICU layout engine,
used by XeTeX and some other systems, is incorrect and may produce the
wrong results on some complex GSUB tables even when the tables themselves
are correct. FontForge's implementation of GSUB substitution in the
metrics window appears to be correct, or at least not to have the same
major bug as ICU.
--
Matthew Skala
http://ansuz.sooke.bc.ca/

Thank you for your reply. I did find some of the feature files generated
cannot be applied back. It gaves syntax error, which is really annoying.
Is it already raised as a bug? If not, where can user report this kind of
error? In general, Fontforge is a quite easy-to-use and powerful tool to
me. I'm still really new in this area...

[m***@ansuz.sooke.bc.ca]

Post by ffnewbie1
Is it already raised as a bug? If not, where can user report this kind of
error? In general, Fontforge is a quite easy-to-use and powerful tool to

There is a bug tracker in the Sourceforge project, but it doesn't appear
to be in active use. The official answer seems to be that we are supposed
to report bugs to this mailing list. I've done that several times and
some of them eventually got fixed, but it's very rare to receive any
official acknowledgement of a bug report. You just have to watch the Git
repository and see if a fix is posted there.

On incorrect saving of feature files, I've mentioned it here a few times,
and I've reported specific small points (for instance, a pointer that was
being checked for null *after* it was dereferenced). Khaled Hosny
recently reported another feature file save issue (having to do with
escaping feature names). I'm not sure that anyone has tried to raise the
*general* issue of feature file incorrectness on the mailing list. My
impression is that the FontForge developers don't regard feature files as
important. I've heard claims that Adobe's implementation isn't correct
either, and I think some people take that as evidence that the feature
file format is not worth bothering with.

I use feature files a lot in my Tsukurimashou project, which is also the
main thing for which I use FontForge at all, and just for my own purposes
I've been tracking relevant FontForge bugs in the Tsukurimashou
user manual. You can find that document, including my workarounds for
the bugs, inside the package at
http://sourceforge.jp/projects/tsukurimashou/downloads/54223/tsukurimashou-0.5.zip/

Unfortunately, the only way I've found to work around incorrectly saved
feature files is to come up with a workflow in which I don't need to save
feature files from FontForge at all.

Something else worth bearing in mind is that there's information lost in
the translation from feature files to binary tables, so even if FontForge
did it correctly, you wouldn't be able to load a feature file into a font,
save it back to a feature file, and get back the same feature file you
started with. It's a lot like compiling and decompiling a program: you
should be able to get something that will compile, but you won't be able
to get the exact original source code. At present FontForge generates
feature files that will not even "compile," though, so there's definitely
room for improvement.

[ffnewbie1]

Post by m***@ansuz.sooke.bc.ca
Unfortunately, the only way I've found to work around incorrectly saved
feature files is to come up with a workflow in which I don't need to save
feature files from FontForge at all.

Thank you for your detailed reply! This is a good idea for work around.
I'll keep it in mind.