[cairo] Scaled fixed size fonts

Fred Kiefer fredkiefer at gmx.de
Sat Jan 18 09:03:46 PST 2014


On which platform did you create these images? The error is only to be
expected if you use the FreeType font interface in cairo.

And when looking at your images I doubt that it is really using the
Adobe Helvetica font. Just compare the "a" with the ones on this page:
http://store1.adobe.com/cfusion/store/html/index.cfm?event=displayFontPackage&nr=0&code=1766&store=OLS-US&newsample=This+is+a+Test&view=View

Please remember that the problem is with fixed sized fonts only.
Scalable fonts work as expected. But for fixed sized fonts the current
cairo code gives horrible results. If you don't have the fixed sized
Adobe Helvetica installed on your machine. try to change the code to use
another fixed sized font.

Fred

On 18.01.2014 17:51, Uli Schlachter wrote:
> On 18.01.2014 13:17, Fred Kiefer wrote:
>> It took me a bit longer to find the time to write up a simple example. I
>> started of with one of the example files I found on this list. It simply
>> creates an SVG surface and writes two lines of text in two different
>> point sizes. Run the code as it is now, copy the result to somewhere
>> save and then exchange the two writing blocks and run it again. In the
>> first case the second line will look horrible in the second case that
>> line is OK, but the first one is unreadable.
>> This proves that for fixed sized fonts the font selection is order
>> dependent and that the first selected font will be scaled for other sizes.
>>
>> Does this explain the issue in enough detail?
> 
> Not really. Attached are two SVGs. The file temp-orig.svg was created by your
> program, the file temp.svg by swapping lines 31-33 with lines 35-37. To my
> untrained eyes, the SVGs look the same.
> 
>> As I explained in my original mail, this has nothing to do with the SVG
>> backend, I only use that to show the issue. It is caused by the way the
>> FT fonts get created. Please take the time to scroll down to the
>> original mail.
>>
>> Fred
>>
>> On 14.01.2014 09:25, Fred Kiefer wrote:
>>> Hi Behdad,
>>>
>>> I hope to find time to write a full example later today. Here a
>>> simple way to reproduce the issue. Create a font face for one of the
>>> Adobe fixed fonts. Create a scaled font with 12 pixel size. Next
>>> create another scaled font from the font face with 24 pixel size use
>>> that for drawing. The 12 pixel font will get used, but scaled to 24
>>> pixel.
>>>
>>> Fred
>>>
>>> On the road
>>>
>>> Am 14.01.2014 um 09:12 schrieb Behdad Esfahbod <behdad at behdad.org>:
>>>
>>>> Hi,
>>>>
>>>> Your message is a bit vague in details.  Do you have a simple test
>>>> case?
>>>>
>>>> behdad
>>>>
>>>>> On 14-01-06 03:48 AM, Fred Kiefer wrote: In the GNUstep project
>>>>> we use cairo as our default drawing backend. One user complained
>>>>> that with cairo some fonts get displayed worse than with the
>>>>> direct xlib based backend. It turns out that on this computer
>>>>> only the Adobe fonts are installed and this are fixed size
>>>>> fonts. I investigated a bit in our code and later in the cairo
>>>>> code and this burns down to the function
>>>>> cairo_scaled_font_create() returning not the best suited fixed
>>>>> size font, but a scaled version of the standard 12 point font.
> 
> I'll assume that I cannot reproduce your issue because I do not have the right
> fonts. Do you happen to know which packages I would have to install on debian
> testing to get different images?
> 
>>>>> The reason is that _cairo_ft_font_face_get_implementation() in 
>>>>> cairo-ft-font.c reuses the same resolved font even when the font
>>>>> isn't scalable and the matrix did change. My suggestion now is to
>>>>> extend the tests in this function to first inspect the pattern
>>>>> whether it is scalable. If it isn't, compare the pixel size of
>>>>> the cached resolved font with the new pixel size (This code needs
>>>>> to be extracted from _cairo_ft_resolve_pattern) and if that
>>>>> doesn't match within certain limits (which might be the hard bit
>>>>> to define) the old resolved font gets thrown away and replaced by
>>>>> a newly created one. Or we leave the cached one alone and just
>>>>> create a new one?
>>>>>
>>>>> This solution will use up more resource than the current one and
>>>>> if there is no better matching fixed pixel font it will result in
>>>>> the same display with a lot more overhead. Still for some cases
>>>>> it will result in better drawn fonts. And for the most common
>>>>> case where scalable fonts get used it will be almost no
>>>>> overhead.
>>>>>
>>>>> Would cairo be willing to accept a patch in this direction? I am
>>>>> willing to write one, but only if this effort isn't completely
>>>>> wasted.



More information about the cairo mailing list