emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ligatures (was: Unify the Platforms: Cairo+FreeType+Harfbuzz Everywh


From: Clément Pit-Claudel
Subject: Re: Ligatures (was: Unify the Platforms: Cairo+FreeType+Harfbuzz Everywhere (except TTY))
Date: Fri, 22 May 2020 10:32:30 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 22/05/2020 10.29, Eli Zaretskii wrote:
>> Cc: address@hidden, address@hidden, address@hidden
>> From: Clément Pit-Claudel <address@hidden>
>> Date: Fri, 22 May 2020 09:26:05 -0400
>>
>>> In general, I envision that people would use the font they find
>>> acceptable for the ligatures they want/need in each mode or buffer
>>> where they need that.  If for some reason different fonts could
>>> determine which ligatures you do NOT want to see, then I guess we will
>>> have to provide some easy-to-use UI for that, which would manipulate
>>> the relevant data structures under the hood.  Alternatively each font
>>> could require a separate composition function to go with it.
>>
>> It would be weird for Emacs to be the only program that requires re-encoding 
>> the entire ligature logic of each font it attempts to use.  Different fonts 
>> offer different ligatures, and if I want to select a subset the font itself 
>> provides variants that let me do this.  Meanwhile, I hope that we can make 
>> Emacs act like browsers or other editors in that if I select a font it will 
>> just, by default, use the ligatures that this font provides according to the 
>> logic embedded in the font.
> 
> If this is a real problem, it should be possible to have a function
> that will extract all the ligatures supported by a font, I think.
> 
> But I don't think I agree with the "logic embedded in the font" part.
> I think we should let the user control which ligatures are really
> used.

I agree.  We should let them control the logic, but that doesn't mean we have 
to force them to do so; which means we need a way to extract that logic, 
somehow.  My udnerstanding was that it could be quite complex, so there was no 
point in re-implementing it in ELisp.



reply via email to

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