Forum > Cocoa

[Solved] Demo to benchmark TextOut on win64/gtk2/Cocoa - Cocoa is very slow

<< < (5/5)

skalogryz:

--- Quote from: davidfjenkins on February 18, 2022, 10:08:03 pm ---What are you using to generate the screen shot with the lower part of the y cut off?  I know it is synedit related but in what format?

--- End quote ---
a plain project with TSynEdit on it and a bunch of lines "SynEdit" set.
nothing special really.
The TSynEdits font is not modified.

davidfjenkins:
I was able to repeat the clipping by setting up the simple SynEdit app.  At first it only repeated if I compiled on macos 10.14 and not my 11.6 machine.  But then we noticed that the default font size for TSynEdit was different between the two

10.14 Font.Height = $0000000A
11.6 Font.Height = -13

When I change to font.height = 10, I was able to repeat the clipping.

I have submitted a new patch in bug report 39660.  The specific issue the patch fixes that caused the clipping is described in the report.  Summary is that I needed to make sure that whereever ascent and/or descent values are used, they are converted from float->integer in the same fashion.

I looked at GetTextMetrics on Windows to see how the conversion ws done there.  It is always Round(ascent) and Round(descent).  cocoagdiobjects.pas now emulates that behavior and is consistent across the three functions GetTextMetrics, GetTextExtentPoint, and TextOut

Zoƫ:
Some additional info related to line layout that we ran into that David's patch doesn't touch on:

There are fonts installed on macOS by default that draw flush to the top of the rect with excessive empty space at the bottom (e.g., DIN Condensed).  Using those same fonts on Windows draws them in the middle of the rect with space both above and below the text like you'd expect.  This is not a bug in LCL.  It turns out the TTF font files actually have two different headers that store the ascent/descent/leading values, and they aren't guaranteed to be in sync.  Windows reads one and macOS uses the other.  Using TextEdit with those same fonts shows the same behavior.

davidfjenkins:
The two headers are HHEA - Horizontal Table Header

  https://docs.microsoft.com/en-us/typography/opentype/spec/hhea

and OS/2 Windows Metrics Table. 

  https://docs.microsoft.com/en-us/typography/opentype/spec/os2

The HHEA has one set of ascent/descent/lead values. that are described as typographic values and are Apple specific (see the msdn documentation above).

ascender
descender
LineGap

The OS/2 windows tables has two sets of values:

sTypoAscender
sTypoDescender
sTypoLineGap

usWinAscent
usWinDescent

I have looked at ttf files that have different values for all three sets though the hhea values and teh sTypo values can be the same.  There is a flag USE_TYPO_METRICS that indicates to use sTypo values instead of usWin values. 

But as Zoe points out, the important point is that the same font file can easily result in different vertical placement of text between Windows and Cocoa.

trev:

--- Quote ---Dependencies

A number of fields in the 'OS/2' table replicate data found elsewhere in the font; most notably, the various ascent and descent fields mirror some of the contents of the horizontal header table. The macOS derives ascent and descent information from the latter; Windows from the former.

Fonts intended to be used on both platforms must have consistent values for the font's ascent and descent in these two tables.
--- End quote ---

Source: https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6OS2.html

So perhaps some fonts are not intended to be used on macOS but only Windows etc.

Navigation

[0] Message Index

[*] Previous page

Go to full version