No, they are needed. Because glyphs must be calculated (getGlyphs:of:)
after(!) setting font size. Otherwise there are huge gaps between
characters.
When font problem appears, some characters are of size 14 even if font size
10. So glyphs of big characters have larger extent as it should be. In your
example you set font size and fix font, so all characters are rendered
correctly, but at wrong positions. That is a source of unnecessary gaps.

Thete is a way to break font:

1) Get new pharo image
2) Get Bloc
3) Switch to bloc
4) remove all morphs
5) save and quite
6) open image
7) open nautilus

Do something to fix font. Repeat 4-7. If fix is "fake" fonts will be
broken..
On Oct 9, 2015 10:31 PM, "Nicolai Hess" <[email protected]> wrote:

>
>
> 2015-10-08 18:05 GMT+02:00 Aliaksei Syrel <[email protected]>:
>
>> Do you remember a hack with scaling? (scaleBy: [email protected]) It makes
>> letters to have the same height, so no more huge ones with small fonts. But
>> it doesn't fix a bug when letters have wrong width so there is a space
>> between characters. The same effect can be achieved if we set font size
>> manually after setting scaled font before drawing glyphs with cairo. It
>> means that at some point we get wrong calculated glyphs. So if we "fix"
>> scaled font before glyph calculation - the problem would be gone. In the
>> patch I set scaled font, manually apply font size, retrieve "fixed" scaled
>> font and calculate glyphs based on it.
>>
>> Also after investigation I found something interesting. If we clean real
>> font of a logical font the problem gets fixed for some period of time. I
>> assume that FreeTypeFont gets broken after a while and logical font always
>> returns broken real font. Setting realFont to nil forces logical font to
>> create a new working free type font. As soon as new free type font is
>> created cairo produces scaled font and caches it. So actual problem lies
>> deep in FreeTypeFont...
>>
>> I even opened two images: one with broken fonts and one with working.
>> Then I compared in inspector two free type fonts - they are absolutely the
>> same and have identical instance variable in a whole object tree, except of
>> handler pointers to C structure which I can't inspect from pharo...
>>
>> Saving image fixes fonts because of
>>
>>> LogicalFont>>shutDown: quitting
>>>   self  allSubInstances do: [:i | i clearRealFont].
>>
>>
>> Cheers,
>> Alex
>>
>
> This is great.
>
> I looked at your change. And noticed the call to
> setFontSize
> this was never called until now. Maybe this was the problem.
>
> Now, I just changed
>
> renderGlyphs: cairoGlyphs
>
>     font lock.
>     canvas
>         setPathMatrix;
>         setScaledFont: font;
>         setFontSize: originalFont pixelSize.  "<< new "
>     canvas paint loadOnCairoCanvas: canvas.
>
>     canvas showGlyphs: cairoGlyphs address size: cairoGlyphs size.
>     font unlock.
>
> And it seems the font issue is gone. Maybe the other changes (set and get
> scaled font in #glyphsOf:from:to: )
> isn't needed? (needs more tests)
>
>
>
>> On Thu, Oct 8, 2015 at 5:43 PM, Nicolai Hess <[email protected]> wrote:
>>
>>> How did you fix it?
>>> Am 08.10.2015 17:06 schrieb "Aliaksei Syrel" <[email protected]>:
>>>
>>>> Hi
>>>>
>>>> It looks like I fixed that weird text rendering problem... Just get the
>>>> latest Athens-Cairo.
>>>>
>>>> Cheers,
>>>> Alex
>>>>
>>>> On Mon, Aug 3, 2015 at 9:32 PM, Nicolai Hess <[email protected]>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> 2015-06-10 12:01 GMT+02:00 Aliaksei Syrel <[email protected]>:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> I noticed that if I force use "Source Code Pro" as standard font for
>>>>>> all elements in the image I never have problems with font rendering. In
>>>>>> case of "Source Sans Pro" font is just not usable becasue of rendering 
>>>>>> bugs
>>>>>> on mac, windows and linux(?). If "Lucida Sans Pro" is used - no bugs too.
>>>>>>
>>>>>> Because bug is reproducable on all platform - it's platform
>>>>>> independent bug.
>>>>>> Because it's reproducable only with one specific font - maybe it's
>>>>>> not an athens issue but bug in font itself and if someone could
>>>>>> change/update Source Sans Pro to a newly version or to a similar font the
>>>>>> problem will be solved?
>>>>>>
>>>>>
>>>>> Did you try to use a new font version ?
>>>>> I don't know exactly how embedded fonts are included. I tried to
>>>>> create the font with  a newer version but it did not work ( or at least I
>>>>> could not see any difference).
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Alex
>>>>>>
>>>>>
>>>>>
>>>>
>>
>

Reply via email to