|
Post by Darkwing on Sept 25, 2021 4:21:48 GMT -5
Hi Allan, hi folks,
I don't know if it's a bug or a feature or maybe even a technical imperative – but the problem is:
When deleting a glyph from the glyphs list — even if it is a freshly added empty glyph slot —, there is a message, that it will also delete the whole 'OpenType table'. This means, the font will loose all its OpenType information.
Why is that? It is very very inconvenient and seems so unnecessary.
I understand, that this might not be a problem if one creates his own OpenType features, but it is a problem when one edits a font made by someone else and wants to keep the OpenType features.
Is there a remedy or an explanation for such a behavior?
Thanks a lot! DW
|
|
|
Post by Allan Murray on Oct 3, 2021 3:18:38 GMT -5
Type 3.2 does allow editing of OpenType tables in a font (few font editors do). You can: 1) generate new OpenType tables 2) keep the existing tables as they are 3) remove all OpenType tables
When glyphs are removed, the integrity of existing tables can not be guaranteed, so 2 is no longer an option.
Instead of deleting the glyph, remove any contours and un-map it. Empty glyph slots like this do not take up any significant space in a font.
|
|
|
Post by Darkwing on Oct 3, 2021 4:27:23 GMT -5
Hm, hm, ok, thanks! I'd argue that under certain conditions the integrity could be guaranteed.
Another question would be: Can the existing OpenType tables be read out and be shown to the user? Or are they really stored in a cryptic unaccessible way, in some kind of bundle that nobody can unwrap?
|
|
|
Post by Allan Murray on Oct 7, 2021 13:58:32 GMT -5
|
|
|
Post by Darkwing on Oct 13, 2021 8:13:05 GMT -5
Hi Allan, I wanted to come back and thank you for the link to DTL OTMaster Light! This is very interesting software, I did not know that such a thing existed. I played a little bit with it I and was even able to export these OpenType Feature definitions – they looked much like the stuff that goes into Type 3.2’s .feax files for including OpenType features: languagesystem DFLT dflt; languagesystem latn dflt;
lookup GPOS_LOOKUP_00000 { lookupflag 8; pos \A \quoteright <0 0 -40 0>; pos \A \quotedblright <0 0 -40 0>; pos \B \quotedblright <0 0 -10 0>; pos \C \period <0 0 -10 0>; pos \C \comma <0 0 -20 0>; pos \D \period <0 0 -10 0>; pos \D \comma <0 0 -20 0>; pos \F \period <0 0 -130 0>; pos \F \comma <0 0 -130 0>; . . . pos \K.ss02 \hyphen <0 0 -50 0>; pos \K.ss02 \endash <0 0 -50 0>; pos \K.ss02 \emdash <0 0 -50 0>; subtable; pos [ \A \glyph40 \Aring \aring] [ \C \G \O \Q \glyph42 \glyph46 \glyph54 \glyph56 \Oslash \oslash] <0 0 -35 0>; pos [ \A \glyph40 \Aring \aring] [ \J \glyph49] <0 0 -20 0>; pos [ \A \glyph40 \Aring \aring] [ \S \glyph58] <0 0 -10 0>; . . . pos [ \Z \glyph65] [ \C \G \O \Q \glyph42 \glyph46 \glyph54 \glyph56 \Oslash \oslash] <0 0 -20 0>; pos [ \Z \glyph65] [ \J \glyph49] <0 0 -20 0>; pos [ \Z \glyph65] [ \A \glyph40 \Aring \AE \aring \ae] <0 0 -10 0>; } GPOS_LOOKUP_00000;
feature kern { lookup GPOS_LOOKUP_00000; } kern;
So I tried to include it , but Type 3.2 seems to not like the lookup statement and results with the following error messages: Invalid command: lookup GPOS_LOOKUP_00000 { Invalid command: lookupflag 8; Only one lookup type per feature block allowed Invalid command: subtable; Invalid command: lookup GPOS_LOOKUP_00000;
Is Type 3.2 capable of dealing with lookup tables in general? Is the lookup table malformed in some way? Is there another way of of including the kerning feature, not by referencing a lookup table? I already tried some things and Type 3.2 created the GPOS table, but it was empty with no information in it. Can you point me in the right direction? Thanks so far! DW
|
|
|
Post by Allan Murray on Oct 18, 2021 2:38:11 GMT -5
The feature syntax used in Type is slightly different to Adobe format.
The equivalent would be:
languagesystem DFLT dflt; languagesystem latn dflt;
feature kern { pos A quoteright <0 0 -40 0>; pos A quotedblright <0 0 -40 0>; pos B quotedblright <0 0 -10 0>; pos C period <0 0 -10 0>; pos C comma <0 0 -20 0>; pos D period <0 0 -10 0>; pos D comma <0 0 -20 0>; pos F period <0 0 -130 0>; pos F comma <0 0 -130 0>; pos K.ss02 hyphen <0 0 -50 0>; pos K.ss02 endash <0 0 -50 0>; pos K.ss02 emdash <0 0 -50 0>; } kern;
@group1=[ A glyph40 Aring aring ]; @group2=[ C G O Q glyph42 glyph46 glyph54 glyph56 Oslash oslash ] @group3=[ J glyph49 ] @group4=[ Z glyph65 ] @group5=[ S glyph58 ] @group6=[ A glyph40 Aring AE aring ae ]
feature kern { pos @group1 @group2 <0 0 -35 0>; pos @group1 @group3 <0 0 -20 0>; pos @group1 @group5 <0 0 -10 0>; pos @group4 @group2 <0 0 -20 0>; pos @group4 @group3 <0 0 -20 0>; pos @group4 @group6 <0 0 -10 0>; } kern;
Yes, the recommended way to output kerning is to add pairs using the kerning window, then select the openType feature called "kerning" which is included with the install. This is a special feature which exports the kerning pairs from the kerning window to OpenType kerning:
# Include Kerning pairs as OpenType kerning
languagesystem DFLT dflt; languagesystem latn dflt;
feature kern { include (features.kerning) } kern;
# include (features.kerning) will include the KERN table as a pair position lookup.
|
|
|
Post by Darkwing on Oct 24, 2021 11:17:57 GMT -5
Thanks Allan, I understand! I now also found the respective chapter and appendix in Type3help.pdf. Will work through this and see if I can achieve my goals. Looks to me, that a converter script from Adobe syntax to Type3 syntax would be my friend. I just want to be able to "manually preserve" (extract and re-include) the present OpenType features of a font.
|
|
|
Post by jacobcart on Jan 7, 2023 3:46:44 GMT -5
thanks for this tread
|
|