Fwd: [Pharo-dev] Font problem is still there

In Pharo 3.0 this is is normal because FreeSans does not exist.

I think that we should embed a default FT font and use is as default. 

Now since embedded fonts are lost when reloading Freetrype fonts.

The reloading of FreeType should be fixed.

Stef

And :

AthensSceneView new scene: [ :canvas | |s| 

                 canvas setFont: (LogicalFont familyName: 'FreeSans' pointSize: 20).

                s:= String newFrom: ($A to: $Z),($a to: $z), ($0 to: $9).

               

                canvas pathTransform restoreAfter: [

                               canvas pathTransform translateX: 0 Y: 50.

                               canvas setPaint: Color black.

                               canvas drawString:s ]

               

];openInWindow

 

And I got :

<image001.png>

<image002.png>

 

And under a fresh Pharo 3.0 :

 

<image003.png>

 

Vincent

 

De : [hidden email] [[hidden email]] De la part de Tudor Girba
Envoyé : vendredi 28 mars 2014 14:28
À : Moose-related development
Objet : [Moose-dev] Re: Fwd: [Pharo-dev] Font problem is still there

 

Hi,

 

This was discussed before both on the Moose and on the Pharo mailing list. We are loading explicitly an older version of Athens because we could not work at all with the one that came from Pharo, and nobody reacted at the time to the font issue:

 

GTImageSetupCommandLineHandler>>loadOlderAthensPackagesToCorrectTheFontCachingProblem

"

This is a workaround fir the bug described here:

https://pharo.fogbugz.com/f/cases/12777/Athens-font-cacheing-bug

"

Gofer new 

smalltalkhubUser: 'Pharo' project: 'Pharo30';

package: 'Athens-Cairo' constraint: [ :version |

version author = 'MarcusDenker' and: [ version versionNumber = 51 ] ];

package: 'Athens-Core' constraint: [ :version | 

version author = 'MarcusDenker' and: [ version versionNumber = 34 ] ];

load

 

Now it's great that you are looking at it. So, I now removed it from the setup and the image is now relying on the latest Pharo 3.0. The build is running now:

https://ci.inria.fr/moose/job/moose-5.0/1008/

 

Cheers,

Doru

 

 

 

On Fri, Mar 28, 2014 at 2:18 PM, Stéphane Ducasse <[hidden email]> wrote:

Hi guys.

 

This is strange that moose is using a so old version of Athens.

 

Stef

 

 

Begin forwarded message:

From: Igor Stasenko <[hidden email]>

Subject: Re: [Pharo-dev] Font problem is still there

Date: 28 Mar 2014 14:03:17 GMT+1

To: Pharo Development List <[hidden email]>

Reply-To: Pharo Development List <[hidden email]>

 

so, i checked both in 4.9 and 5.0 Moose images on linux...

got weird results and sometimes crashes.

in 5.0 image the version is:
Athens-Cairo-MarcusDenker.51

 

- this one uses pretty old code, which renders text using 'toy' cairo api for text rendering.

 

in my working image, where i work every day it is:

Athens-Cairo-SvenVanCaekenberghe.64

 

and there's also couple important fixes since .51 as well as different font rendering code which no longer using toy api..

so, guys, if you want me to continue, please try using latest versions and report problems about it,

because it makes no sense to find a fix in something which outdated and thrown away many months ago. 

 

Load the latest dev version of Athens from smalltalkhub (it is version 2.5)

ConfigurationOfAthens loadDevelopment.

try it out.

Here's what i got on latest fresh vanilla out of the box Pharo 3.0 image on linux system:

<image004.jpg>

 

P.S. i am not saying that it is *impossible* that there is problems in new version, just asking you to report problems with that version,

not one which year(s) old.

-- 
Best regards,
Igor Stasenko.

 

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 

--

www.tudorgirba.com

 

"Every thing has its own flow"

---

Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

so, the quick and dirty fix is to put:

CairoGlyph class>>byteAlignment

    NativeBoost platformId = NativeBoostConstants win32PlatformId ifTrue: [  ^ 8 ].
    ^ super byteAlignment

and then:

CairoGlyph rebuildFieldAccessors
CairoGlyphsArray initialize

(note you must run this snippet each time your image changes platform)..

and i need more time to fix it for real, because it is NB issue, to automatically recalculate the structs size

if it changes platform.. (which also means you cannot store instances of struct in image which survive the session)

... damn.. that's going to be complicated.

---

On 28 March 2014 16:27, Igor Stasenko <[hidden email]> wrote:

On 28 March 2014 16:01, Igor Stasenko <[hidden email]> wrote:

Ookkayy..

so, current status:

 - finally we got an agreement that big red square because of font loading issues and font rendering artifacts is two separate issues.

Thanks!

- i am not going to address font-loading issue here and now.. (because we spent time on it earlier today with Stef already and you should have the report on it in separate mail).

- we seem to be agreed that it is best to use same (up-to-date version) of software when reporting issues to work on them. Thanks again. :)

- while on linux and mac things seem to be working fine, i can confirm that there is rendering artifacts (same as reported by Vincent) on Windows.

so i going to explore what causing this problem..

... and found the cause:

On windows, for unknown reason, the structure (cairo_glyph_t) uses different memory space alignment than on mac and linux

fieldsDesc
    ^ #(
    ulong        index;
    double               x;
    double               y;
    )

on mac and linux , the size of this structure in memory = 4 + 8 + 8 = 20 bytes,
on windows, however, due to 8-byte alignment, it is  4 + 8 + 8 + (4 alignment) bytes...

 

this causing the effect that if you copy array of glyphs in memory,
it does not copying whole array by slightly less  (because it uses wrong struct size which is smaller than it is)..

and because of that, you got weird artefacts at the tail of string, replaced by misplaced/invalid characters etc..
because it is basically read from uninitialized part of memory with random data.

i going to fix structure alignment for windows from default 4 bytes to 8 bytes..

but this is not very good news.. because this affecting many things... (as you can imagine, not only cairo/athens working with external structures, which need to be properly aligned).

--
Best regards,
Igor Stasenko.

--
Best regards,
Igor Stasenko.

thanks Igor.

I’m trying to look at the font reloading bug.

On 28 Mar 2014, at 17:19, Igor Stasenko <[hidden email]> wrote:

https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-different-platforms

On 28 March 2014 16:42, Igor Stasenko <[hidden email]> wrote:

so, the quick and dirty fix is to put:

CairoGlyph class>>byteAlignment

    NativeBoost platformId = NativeBoostConstants win32PlatformId ifTrue: [  ^ 8 ].
    ^ super byteAlignment

and then:

CairoGlyph rebuildFieldAccessors
CairoGlyphsArray initialize

(note you must run this snippet each time your image changes platform)..

and i need more time to fix it for real, because it is NB issue, to automatically recalculate the structs size

if it changes platform.. (which also means you cannot store instances of struct in image which survive the session)

... damn.. that's going to be complicated.

---

On 28 March 2014 16:27, Igor Stasenko <[hidden email]> wrote:

On 28 March 2014 16:01, Igor Stasenko <[hidden email]> wrote:

Ookkayy..

so, current status:

 - finally we got an agreement that big red square because of font loading issues and font rendering artifacts is two separate issues.

Thanks!

- i am not going to address font-loading issue here and now.. (because we spent time on it earlier today with Stef already and you should have the report on it in separate mail).

- we seem to be agreed that it is best to use same (up-to-date version) of software when reporting issues to work on them. Thanks again. :)

- while on linux and mac things seem to be working fine, i can confirm that there is rendering artifacts (same as reported by Vincent) on Windows.

so i going to explore what causing this problem..

... and found the cause:

On windows, for unknown reason, the structure (cairo_glyph_t) uses different memory space alignment than on mac and linux

fieldsDesc
    ^ #(
    ulong        index;
    double               x;
    double               y;
    )

on mac and linux , the size of this structure in memory = 4 + 8 + 8 = 20 bytes,
on windows, however, due to 8-byte alignment, it is  4 + 8 + 8 + (4 alignment) bytes...

 

this causing the effect that if you copy array of glyphs in memory,
it does not copying whole array by slightly less  (because it uses wrong struct size which is smaller than it is)..

and because of that, you got weird artefacts at the tail of string, replaced by misplaced/invalid characters etc..
because it is basically read from uninitialized part of memory with random data.

i going to fix structure alignment for windows from default 4 bytes to 8 bytes..

but this is not very good news.. because this affecting many things... (as you can imagine, not only cairo/athens working with external structures, which need to be properly aligned).

--
Best regards,
Igor Stasenko.

--
Best regards,
Igor Stasenko.

--
Best regards,
Igor Stasenko.