Re: fonts displaying strangely

[Eric Wasylishen]

Hi Fred,

On 2011-10-31, at 3:26 PM, Fred Kiefer wrote:

> Hi Eric,
> 
> I don't think that this patch is the way to proceed. You implement a few 
> different ideas in there that will each cost a lot of runtime. It surely is a 
> great idea to move the determination of the colours into a separate method, 
> but we should only get the one current colour plus its valid range from that 
> method and not compute more at once.

Hm.. good idea, that should be possible with little change to the existing 
method I wrote, and gets rid of the overhead of creating the attributed string 
data structure to store the results in.

> And sending each glyph over to the backend separately is definitely wrong. We 
> just need to make sure that the advancements we compute in the layout manager 
> match the actual advancements. You change just spreads out that error over 
> all glyphs, while the current code shows it at the end of a glyph run that 
> got displayed at once.

Right, that part of the patch was an experiment to see if I could get correct 
output ignoring performance.

My idea of how to proceed is something like this:
- add a method to NSLayoutManager for getting a range of glyphs and their 
advances as efficiently as possible, which should not be difficult (or maybe we 
already have that?).   I'm not sure if I advertised it well, but I made a 
change in NSLayoutManager several months ago so that we store advancements 
along with the glyphs in the glyph run data structure (previously, the 
advancements were not stored.The reason for this change is so in the future we 
can implement a glyph generator which does complex text layout, by calling a 
library such as harfbuzz or icu, since these take a character run and output a 
glpyh run with advancements.)
- properly implement GSShowGlyphsWithAdvances in the backends. easy for cairo, 
at least.
- for cairo, it would be nice to use real glyphs by importing the code from 
Opal that Neils and I wrote.

The pseudocode for -drawGlyphsForGlyphRange:atPoint: should look something like 
this:

for the range to be drawn:
        - get the first subrange with the same colour
        - get the glyphs in that subrange and their advances as efficiently as 
possible
        - set the colour, and send the glyphs and advances to the backend with 
GSShowGlyphsWithAdvances
        - start the next loop iteration, starting at the end of the current 
subrange

Regards,
Eric

> 
> Fred
> 
> On 31.10.2011 20:46, Eric Wasylishen wrote:
>> Hi Sebastian,.
>> I see something similar if I increase the UI scale factor with 
>> GSScaleFactor, except text has gaps in it instead of being bunched together.
>> 
>> I tracked that problem to the method -[NSLayoutManager 
>> drawGlyphsForGlyphRange:atPoint:] which is hard to understand and seems to 
>> be buggy.  I started a rewrite of that method a while ago but never finished 
>> it. If you want, you could try applying the attached patch and see if it 
>> fixes your problem.
>> 
>> The patch fixes the spacing problems I observed, but it is incomplete; it 
>> may not properly change styles when drawing an attributed string (and it's 
>> also slow) - so it's not ready to apply.
>> 
>> Eric
>> 
>> 
>> 
>> 
>> 
>> 
>> On 2011-10-31, at 10:25 AM, Sebastian Reitenbach wrote:
>> 
>>> Hi,
>>> 
>>> don't know when this started, or maybe its a default I've set?
>>> Some texts in applications are looking fairly ugly. Some letters appear 
>>> fairly squeezed together. On the console I don't see any warnings regarding 
>>> fonts. Also the cursor in GWorkspace Run dialog is blinking in the middle 
>>> of the last typed letter, not after it.
>>> See attached screenshot, its not only in gworkspace, all apps seem to have 
>>> this problem. I'm using latest svn.
>>> 
>>> Sebastian<gworkspace.png>_______________________________________________
> 
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep