I have a question:
It's possible that 2 characters in the adjustment database could map to the
same glyph, which will create 2 entries in the reverse character map with
the same glyph as a key. In this case, the character that glyph maps to is
decided arbitrarily based on which one the binary search chooses and which
order qsort puts them in.
What should be done in these cases?
On Tue, Sep 26, 2023 at 11:17 PM Craig White <gerzy...@gmail.com> wrote:
> > Thanks. Do you have meanwhile found an explanation why o-tilde looks
> so bad for Times New Roman at 16ppem?
>
> All 4 letters in each row have a different approach:
>
> õ: vertical stretch, no segment removal
> ñ: no vertical stretch, segment removal
> ã: vertical stretch and segment removal
> all other tildes: no changes applied
>
> Actually, I tried the o tilde character again with no adjustments and it
> looked the same. In this case, the vertical stretch wasn't enough to fix
> the issue.
>
> > Sounds good. Unfortunately, I'm a bit short of time right now; I'll
> think about your algorithm within the next few days. However, please
> proceed anyway!
> I implemented the algorithm for all glyph variants! The version I used is
> different from what I wrote originally to fix some errors. Here's the
> current version:
> results is now a global set of glyphs instead of an argument to the
> function. It initially starts empty
> fs is a global set of features, also initially empty
> all other definitions are the same
>
> func all_glyphs(codepoint c)
> {
> result = result ∪ lookup(c, fs)
> foreach (feature f ∈ (features - fs)) //for all features not already
> in fs
> {
> new_glyphs = lookup(c, fs ∪ f) - result
> if (new_glyphs != ∅)
> {
> result = result ∪ new_glyphs
> fs = fs ∪ f
> all_glyphs(c)
> fs = fs - f
> }
> }
> }
> I've only tried it on a pretty simple case so far, so I'll need to
> assemble a more complex test font or two.
>
> On Mon, Sep 18, 2023, 4:03 AM Werner LEMBERG <w...@gnu.org> wrote:
>
>>
>> > Is testing all these combinations really necessary?
>>
>> I don't know :-) I just wanted to point out that feature combinations
>> have to be considered.
>>
>> > [...] My intuition says very few of these combinations actually
>> > matter.
>>
>> Yes, I agree.
>>
>> > I wrote some pseudocode for a different approach that I believe
>> > accomplishes the same thing, while being more efficient and hopefully
>> > removing the need to constrain the set of features considered: [...]
>>
>> Sounds good. Unfortunately, I'm a bit short of time right now; I'll
>> think about your algorithm within the next few days. However, please
>> proceed anyway!
>>
>> > I attached some pictures of the tilde unflattening approaches.
>>
>> Thanks. Do you have meanwhile found an explanation why o-tilde looks
>> so bad for Times New Roman at 16ppem?
>>
>> > I chose sizes that showcase the differences between the approaches,
>> > and also committed my current code if you would like to try it
>> > yourself.
>>
>> Will try if I find some time.
>>
>>
>> Werner
>>
>
