Does OTD have, or plan to implement, something along the lines of the following debugging tools:
Given a string that produces an unexpected result, one needs to search for the relevant glyph and for the lookups that contain it. For example, VOLT has an Explorer in which one can look for a glyph in GSUB, GPOS, contextuals, and groups (=classes). Not perfect but it has saved this writer enormous amounts of time.
If there is already a way to do this, could not find it.
In Preview, we can select features, but not lookups within features. Given a lookup sequence that produces a result, it helps to be able to look at the results step by step. VOLT has its own implementation of this idea; does OTD have, or plan to implement, anything similar in this regard?
Within the OTD paradigm as is, what are some standard practices currently used to debug lookups?
For example, Preview gives the name of the glyph string beneath the preview. But sometimes we need to be able to trace back each glyph through its relevant lookup sequence to its original Unicode input etc…
In the OpenType Designer Preview area, click on the glyph to go to relevant lookup or on the Preview Toolbar to go to the relevant glyph in the Glyph Overview.
In OTD, Preview, enter this Unicode string and select Arabic (arab) from the top left of the features pane: لحمد
Glyph string result appears at the bottom: /LamIni.outD2H/HahMed.inD2outD2MM/MeemMed.inD2outT1/DalFin
Toggle rlig:
Before rlig: HahMed
After rlig: HahMed.inD2outD2MM
Challenge: Find the correct table and lookup(s) which govern the substitution of HahMed with HahMed.inD2outD2MM - there may be intermediate substitutions
What is the most efficient way to do this?
(Clicking on the glyph in Preview takes one to the relevant curs lookup - we want rlig).
(One could export an otlfd file and search but depending on classes etc that could be unwieldy - this should be doable from the GUI).
(Idea: Given a glyph in the resultant glyph string below Preview, come up with a reasonable way to select and see what lookups it participates in. Etc.)
With rlig on, click on rightmost character in Preview: This takes us to SingleSubstitution33.
Go to Features - RequiredLigatures (rlig) in the left pane.
Challenge: Find a the contextual chain that calls SingleSubstitution33 - I could not find it.
Exported an otlfd to look for clues - no luck.
Spent over an hour trying to solve this within the GUI and text export.
Aside from this font, in my own project - at least five times as many lookups and over a dozen times as many features compared to this one - often need to be able to debug quickly. At the moment, doing this in OTD is very inefficient.
Apologies if this follow-up appears to constitute a gilding of the lily Kindly take it in the spirit of sharing experiences as the developers continue to think of creative ways to improve functionality. Many thanks.
Right now this output is not available in the public release. I’ve only recently added in the debug version while improving the Preview feature.
I’m considering adding it as I know it is very useful, but I’m not sure if this is the right way and if it should only be available in the Professional edition or if we should introduce a Super edition for $499
Many thanks. Will study your replies closely and try to reply over this weekend. As for the Super Edition; will be happy to invest in that to complete and have the best OpenType Designer ever
Wow, was going around in circles for hours trying to figure this out.
So there is either a bug in the gui, or it is misleading, or both : SingleSubstitution32 is the only table that appears in the right column under Substitution Tables and is also the first entry in the Code Editor representation. The gui gives the impression that SingleSubstitution32 is the only rule table contained within ChainingContext7. One of the things tried was to go through every ChainingContext under rlig and to examine its substitution tables. Via the gui, could not find anything, which was perplexing.
So the gui appears to need some work here
It never came to mind that the gui was not correctly representing the lookups. So what was needed was to compare the gui representation with the otlfd export: That means going through each lookup manually searching for SingleSubstitution33. SingleSubstitution33 is mentioned 62 times in the otlfd file: There has got to be a better way!
Also, do not see any reference to, e.g., Rule 5 in the Code Editor. Where are these rules indexed?
Many thanks for your patience with these persistent inquiries during this struggle to grasp the power and limitations of OTD, and to formulate helpful suggestions.
See what you mean, yet it works.. Could you point to a place in the spec or elsewhere that proscribes applying a lookup on the same index twice? Instructive example, don’t think one could do this in VOLT.. think that one would have to split this operation into two separate contextual lookups..
This is what ConTeXt gives (uses pre-release code, still testing):
feature ‘rlig’, type ‘gsub_contextchain’, chain lookup ‘s_s_27’, replacing single
U+F0139 (LamIni) by U+F014D (LamIni.outD2H)
feature ‘rlig’, type ‘gsub_contextchain’, chain lookup ‘s_s_27’, replacing single
U+F01E8 (HahMed) by U+F02C9 (HahMed.inD2)
feature ‘rlig’, type ‘gsub_contextchain’, chain lookup ‘s_s_27’, replacing single
U+F02C9 (HahMed.inD2) by U+F0246 (HahMed.inD2outD2MM)
feature ‘rlig’, type ‘gsub_contextchain’, chain lookup ‘s_s_27’, replacing single
U+F0136 (MeemMed) by U+F02CB (MeemMed.inD2)
feature ‘rlig’, type ‘gsub_contextchain’, chain lookup ‘s_s_27’, replacing single
U+F02CB (MeemMed.inD2) by U+F02D2 (MeemMed.inD2outT1)
Kindly take it in the spirit of sharing experiences as the developers continue to think of creative ways to improve functionality. Many thanks.
y (0, 0) wh (0, 0)
