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" <nicolaihess@web.de> wrote:
2015-10-08 18:05 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:
Do you remember a hack with scaling? (scaleBy: 1.0001@1.0001) 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 <nicolaihess@web.de> wrote:
How did you fix it? Am 08.10.2015 17:06 schrieb "Aliaksei Syrel" <alex.syrel@gmail.com>:
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 <nicolaihess@web.de> wrote:
2015-06-10 12:01 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:
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