Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there
De : moose-dev-bounces@iam.unibe.ch [mailto:moose-dev-bounces@iam.unibe.ch] De la part de Stéphane Ducasse Envoyé : vendredi 28 mars 2014 15:30 à : Moose-related development Cc : Pharo Development List Objet : [Moose-dev] Re: [Pharo-dev] Re: Re: Fwd: Font problem is still there On 28 Mar 2014, at 14:55, Tudor Girba <tudor@tudorgirba.com<mailto:tudor@tudorgirba.com>> wrote: In the Moose image, the fonts are already set to free type fonts. yes but if you uncheck and recheck freetype the embedded fonts are lost -> substition -> substitution failed. -> get a strike font and boum. I confirm ! [cid:image001.png@01CF4A9B.F64977F0] [cid:image002.png@01CF4A9B.F64977F0] And if you can see under the A character, there is a square that should not be here... (under w7) Vincent Doru On Fri, Mar 28, 2014 at 2:50 PM, Blondeau Vincent <vincent.blondeau@worldline.com<mailto:vincent.blondeau@worldline.com>> wrote: No, I did not change the Free type in the pharo settings. But if I do it under Moose, I got : <image001.png> De : moose-dev-bounces@iam.unibe.ch<mailto:moose-dev-bounces@iam.unibe.ch> [mailto:moose-dev-bounces@iam.unibe.ch<mailto:moose-dev-bounces@iam.unibe.ch>] De la part de Stéphane Ducasse Envoyé : vendredi 28 mars 2014 14:44 à : Pharo Development List Cc : Moose-related development Objet : [Moose-dev] Re: [Pharo-dev] Re: Fwd: Font problem is still there vincent Did you changed the freetype settings? Setf On 28 Mar 2014, at 14:36, Blondeau Vincent <vincent.blondeau@worldline.com<mailto:vincent.blondeau@worldline.com>> wrote: +1. So, I did on a fresh Moose 5.0 Image under W7: Gofer new smalltalkhubUser: 'Pharo' project: 'Athens'; configuration; loadDevelopment. 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 : moose-dev-bounces@iam.unibe.ch<mailto:moose-dev-bounces@iam.unibe.ch> [mailto:moose-dev-bounces@iam.unibe.ch] 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 <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: Hi guys. This is strange that moose is using a so old version of Athens. Stef Begin forwarded message: From: Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> Subject: Re: [Pharo-dev] Font problem is still there Date: 28 Mar 2014 14:03:17 GMT+1 To: Pharo Development List <pharo-dev@lists.pharo.org<mailto:pharo-dev@lists.pharo.org>> Reply-To: Pharo Development List <pharo-dev@lists.pharo.org<mailto:pharo-dev@lists.pharo.org>> 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 Moose-dev@iam.unibe.ch<mailto:Moose-dev@iam.unibe.ch> https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com<http://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. ________________________________ 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. -- www.tudorgirba.com<http://www.tudorgirba.com/> "Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch<mailto:Moose-dev@iam.unibe.ch> https://www.iam.unibe.ch/mailman/listinfo/moose-dev ________________________________ 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.
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.. -- Best regards, Igor Stasenko.
On 28 March 2014 16:01, Igor Stasenko <siguctua@gmail.com> 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.
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 <siguctua@gmail.com> wrote:
On 28 March 2014 16:01, Igor Stasenko <siguctua@gmail.com> 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.
https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-differ... On 28 March 2014 16:42, Igor Stasenko <siguctua@gmail.com> 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 <siguctua@gmail.com> wrote:
On 28 March 2014 16:01, Igor Stasenko <siguctua@gmail.com> 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.
thanks Igor. Iâm trying to look at the font reloading bug. On 28 Mar 2014, at 17:19, Igor Stasenko <siguctua@gmail.com> wrote:
https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-differ...
On 28 March 2014 16:42, Igor Stasenko <siguctua@gmail.com> 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 <siguctua@gmail.com> wrote:
On 28 March 2014 16:01, Igor Stasenko <siguctua@gmail.com> 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.
okay i uploaded updated configs for NativeBoost and Athens into official repositories for these projects. Gofer new smalltalkhubUser: 'Pharo' project: 'NativeBoost'; configuration; load. ConfigurationOfNativeBoost loadDevelopment. Gofer new smalltalkhubUser: 'Pharo' project: 'Athens'; configuration; load. ConfigurationOfAthens loadDevelopment. shall do the trick.. for more details see https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-differ... On 28 March 2014 21:13, Pharo4Stef <pharo4Stef@free.fr> wrote:
thanks Igor. Iâm trying to look at the font reloading bug.
On 28 Mar 2014, at 17:19, Igor Stasenko <siguctua@gmail.com> wrote:
https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-differ...
On 28 March 2014 16:42, Igor Stasenko <siguctua@gmail.com> 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 <siguctua@gmail.com> wrote:
On 28 March 2014 16:01, Igor Stasenko <siguctua@gmail.com> 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.
-- Best regards, Igor Stasenko.
Is this supposed to fix the font rendering problem or some other font problem? I tried it and it doesn't seem to help the rendering problem. Cheers, Jeff On Tue, Apr 1, 2014 at 6:27 PM, Igor Stasenko <siguctua@gmail.com> wrote:
okay i uploaded updated configs for NativeBoost and Athens into official repositories for these projects.
Gofer new smalltalkhubUser: 'Pharo' project: 'NativeBoost'; configuration; load.
ConfigurationOfNativeBoost loadDevelopment.
Gofer new smalltalkhubUser: 'Pharo' project: 'Athens'; configuration; load.
ConfigurationOfAthens loadDevelopment.
shall do the trick..
for more details see
https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-differ...
On 28 March 2014 21:13, Pharo4Stef <pharo4Stef@free.fr> wrote:
thanks Igor. I'm trying to look at the font reloading bug.
On 28 Mar 2014, at 17:19, Igor Stasenko <siguctua@gmail.com> wrote:
https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-differ...
On 28 March 2014 16:42, Igor Stasenko <siguctua@gmail.com> 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 <siguctua@gmail.com> wrote:
On 28 March 2014 16:01, Igor Stasenko <siguctua@gmail.com> 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.
-- Best regards, Igor Stasenko.
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
On 02 Apr 2014, at 14:46, J.F. Rick <self@je77.com> wrote:
Is this supposed to fix the font rendering problem or some other font problem? I tried it and it doesn't seem to help the rendering problem.
normally it should fix the font PrObLem can you check that you loaded the latest NB?
Cheers,
Jeff
On Tue, Apr 1, 2014 at 6:27 PM, Igor Stasenko <siguctua@gmail.com> wrote: okay i uploaded updated configs for NativeBoost and Athens into official repositories for these projects.
Gofer new smalltalkhubUser: 'Pharo' project: 'NativeBoost'; configuration; load.
ConfigurationOfNativeBoost loadDevelopment.
Gofer new smalltalkhubUser: 'Pharo' project: 'Athens'; configuration; load.
ConfigurationOfAthens loadDevelopment.
shall do the trick..
for more details see https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-differ...
On 28 March 2014 21:13, Pharo4Stef <pharo4Stef@free.fr> wrote: thanks Igor. Iâm trying to look at the font reloading bug.
On 28 Mar 2014, at 17:19, Igor Stasenko <siguctua@gmail.com> wrote:
https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-differ...
On 28 March 2014 16:42, Igor Stasenko <siguctua@gmail.com> 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 <siguctua@gmail.com> wrote:
On 28 March 2014 16:01, Igor Stasenko <siguctua@gmail.com> 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.
-- Best regards, Igor Stasenko.
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
Cool. I just loaded the latest NB and Athens (as Igor sent around) but my image is not fully up to date. I'll try downloading a new one and reloading my work from packages. I just wanted to make sure that this was worth the effort. If that doesn't work, then I'll send Igor my image. Cheers, Jeff On Wed, Apr 2, 2014 at 10:55 PM, Pharo4Stef <pharo4Stef@free.fr> wrote:
On 02 Apr 2014, at 14:46, J.F. Rick <self@je77.com> wrote:
Is this supposed to fix the font rendering problem or some other font problem? I tried it and it doesn't seem to help the rendering problem.
normally it should fix the font PrObLem can you check that you loaded the latest NB?
Cheers,
Jeff
On Tue, Apr 1, 2014 at 6:27 PM, Igor Stasenko <siguctua@gmail.com> wrote:
okay i uploaded updated configs for NativeBoost and Athens into official repositories for these projects.
Gofer new smalltalkhubUser: 'Pharo' project: 'NativeBoost'; configuration; load.
ConfigurationOfNativeBoost loadDevelopment.
Gofer new smalltalkhubUser: 'Pharo' project: 'Athens'; configuration; load.
ConfigurationOfAthens loadDevelopment.
shall do the trick..
for more details see
https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-differ...
On 28 March 2014 21:13, Pharo4Stef <pharo4Stef@free.fr> wrote:
thanks Igor. I'm trying to look at the font reloading bug.
On 28 Mar 2014, at 17:19, Igor Stasenko <siguctua@gmail.com> wrote:
https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-differ...
On 28 March 2014 16:42, Igor Stasenko <siguctua@gmail.com> 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 <siguctua@gmail.com> wrote:
On 28 March 2014 16:01, Igor Stasenko <siguctua@gmail.com> 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.
-- Best regards, Igor Stasenko.
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
Okay. One more time. This is interference between Cairo and Freetype plugin.. if you using same font as rest of pharo (drawn outside of Athens) and then the very same font for rendering with Athens, then you will get weird font artifacts, because in-image freetype code uses different scale units for fonts than cairo.. which results in that different glyphs of same font size will be rendered at different scale.. the recipe is simple: - pick your favorite font, and never, ever use it outside of Athens in pharo ui. (prevent it from being used by default freetype font renderer for morphic canvas) -- Best regards, Igor Stasenko.
Okay, i think i got it.. Here is what happens: - the font size is usually specified in points, not x@y points, but typographical points, which is 1/72 inch TextStyle pointsToPixels: 14 TextStyle pointsToPixels: 14 => 18.666666666666668 pointsToPixels: points ^points * self pixelsPerInch / 72.0 but in Athens, i , stupid idiot, completely forgot about that, and use point size directly, to scale up font .. but the point is that this scaling performed in font units (EMs). so, to actually scale font correctly, i must use same TextStyle pointsToPixels: .. as Freetype package using.. there is one caveat, that if you really want to see exactly , say 16 points sized font on your screen, it is not possible without knowing the display resolution - how many pixels in one inch (hence #pixelsPerInch ). Unfortunately, our VMs don't give us a way to determine DPI of display.. and so, it is always 96 :/ pheww.... fromFreetypeFont: aFont cairoFace: face ..... - fontMatrix scaleBy: aFont pointSize. + fontMatrix scaleBy: (TextStyle pointsToPixels: aFont pointSize). problem solved ... (i hope) :) -- Best regards, Igor Stasenko.
On Fri, Apr 04, 2014 at 02:55:01AM +0200, Igor Stasenko wrote:
there is one caveat, that if you really want to see exactly , say 16 points sized font on your screen, it is not possible without knowing the display resolution - how many pixels in one inch (hence #pixelsPerInch ). Unfortunately, our VMs don't give us a way to determine DPI of display.. and so, it is always 96 :/
pheww....
I don't think there is any way for the VM to know the #pixelsPerInch of the display, regardless of the display resolution. Maybe that implies that some calibration would be needed in the image to relate font points to the physical display. Dave
I don't think there is any way for the VM to know the #pixelsPerInch of the display, regardless of the display resolution.
There is no api in the OS for that? It would be really strange that we cannot know such information.
Maybe that implies that some calibration would be needed in the image to relate font points to the physical display.
Dave
On 4 April 2014 08:35, Pharo4Stef <pharo4Stef@free.fr> wrote:
I don't think there is any way for the VM to know the #pixelsPerInch of
the
display, regardless of the display resolution.
There is no api in the OS for that? It would be really strange that we cannot know such information.
There is, of course. Usually, display drivers can provide such information. But still you not always can know the physical dimensions of your display: - consider trying to measure DPI of display which actually a wall projector :) Anyways, i doesn't really matters what is DPI of the screen.. since with with vector graphics you are free at any moment to zoom in/out things to most pleasant scale. And therefore, font size in points becomes more like a relative measurement, rather than absolute (you know that font with of 20 points size will be 2 times bigger than same font with 10 points size)
Maybe that implies that some calibration would be needed in the image to relate font points to the physical display.
Dave
-- Best regards, Igor Stasenko.
Igor I was wondering the following: ? But TextStyle is not about strikefont? Stef On 04 Apr 2014, at 02:55, Igor Stasenko <siguctua@gmail.com> wrote:
Okay, i think i got it..
Here is what happens: - the font size is usually specified in points, not x@y points, but typographical points, which is 1/72 inch
TextStyle pointsToPixels: 14
TextStyle pointsToPixels: 14 => 18.666666666666668
pointsToPixels: points ^points * self pixelsPerInch / 72.0
but in Athens, i , stupid idiot, completely forgot about that, and use point size directly, to scale up font .. but the point is that this scaling performed in font units (EMs).
so, to actually scale font correctly, i must use same TextStyle pointsToPixels: .. as Freetype package using..
there is one caveat, that if you really want to see exactly , say 16 points sized font on your screen, it is not possible without knowing the display resolution - how many pixels in one inch (hence #pixelsPerInch ). Unfortunately, our VMs don't give us a way to determine DPI of display.. and so, it is always 96 :/
pheww....
fromFreetypeFont: aFont cairoFace: face .....
- fontMatrix scaleBy: aFont pointSize.
+ fontMatrix scaleBy: (TextStyle pointsToPixels: aFont pointSize).
problem solved ... (i hope) :)
-- Best regards, Igor Stasenko.
On 4 April 2014 08:33, Pharo4Stef <pharo4Stef@free.fr> wrote:
Igor
I was wondering the following: ? But TextStyle is not about strikefont?
TextStyle contains so many different things..
Stef
On 04 Apr 2014, at 02:55, Igor Stasenko <siguctua@gmail.com> wrote:
Okay, i think i got it..
Here is what happens: - the font size is usually specified in points, not x@y points, but typographical points, which is 1/72 inch
TextStyle pointsToPixels: 14
TextStyle pointsToPixels: 14 => 18.666666666666668
pointsToPixels: points ^points * self pixelsPerInch / 72.0
but in Athens, i , stupid idiot, completely forgot about that, and use point size directly, to scale up font .. but the point is that this scaling performed in font units (EMs).
so, to actually scale font correctly, i must use same TextStyle pointsToPixels: .. as Freetype package using..
there is one caveat, that if you really want to see exactly , say 16 points sized font on your screen, it is not possible without knowing the display resolution - how many pixels in one inch (hence #pixelsPerInch ). Unfortunately, our VMs don't give us a way to determine DPI of display.. and so, it is always 96 :/
pheww....
fromFreetypeFont: aFont cairoFace: face .....
- fontMatrix scaleBy: aFont pointSize.
+ fontMatrix scaleBy: (TextStyle pointsToPixels: aFont pointSize).
problem solved ... (i hope) :)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Woohoo! Works for me. You made my day. In regards to determining the DPI of the display, can't we just set that as a preference with a default value of 96? That would satisfy 98% of cases. We could also add a primitive that would allow the VM to have its say (e.g., retina display on MacOS). When that primitive fails, it would default to the preference. Cheers, Jeff On Fri, Apr 4, 2014 at 2:55 AM, Igor Stasenko <siguctua@gmail.com> wrote:
Okay, i think i got it..
Here is what happens: - the font size is usually specified in points, not x@y points, but typographical points, which is 1/72 inch
TextStyle pointsToPixels: 14
TextStyle pointsToPixels: 14 => 18.666666666666668
pointsToPixels: points ^points * self pixelsPerInch / 72.0
but in Athens, i , stupid idiot, completely forgot about that, and use point size directly, to scale up font .. but the point is that this scaling performed in font units (EMs).
so, to actually scale font correctly, i must use same TextStyle pointsToPixels: .. as Freetype package using..
there is one caveat, that if you really want to see exactly , say 16 points sized font on your screen, it is not possible without knowing the display resolution - how many pixels in one inch (hence #pixelsPerInch ). Unfortunately, our VMs don't give us a way to determine DPI of display.. and so, it is always 96 :/
pheww....
fromFreetypeFont: aFont cairoFace: face .....
- fontMatrix scaleBy: aFont pointSize.
+ fontMatrix scaleBy: (TextStyle pointsToPixels: aFont pointSize).
problem solved ... (i hope) :)
-- Best regards, Igor Stasenko.
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
On 4 April 2014 11:17, J.F. Rick <self@je77.com> wrote:
Woohoo! Works for me. You made my day.
yeah.. i am happy i figured it out finally :) i now making some cleanup and lill optimizations before committing the update.
In regards to determining the DPI of the display, can't we just set that as a preference with a default value of 96? That would satisfy 98% of cases.
it is already like that.. see TextStyle class>>#pixelsPerInch / #pixelsPerInch:
We could also add a primitive that would allow the VM to have its say (e.g., retina display on MacOS). When that primitive fails, it would default to the preference.
sure.. one day we may add it. but in fact, who cares? if you think in terms of vectors, knowing screen DPI is something you largely don't need.. because DPI is thinking in terms of pixels :) As soon as you give user a way to zoom things in/out to make things convenient to him, it will no longer matter what is the absolute values like font sizes in UI design, the only thing what will matter is relative sizes between UI elements (like: here i want 2 times bigger font than here etc)
Cheers,
Jeff
On Fri, Apr 4, 2014 at 2:55 AM, Igor Stasenko <siguctua@gmail.com> wrote:
Okay, i think i got it..
Here is what happens: - the font size is usually specified in points, not x@y points, but typographical points, which is 1/72 inch
TextStyle pointsToPixels: 14
TextStyle pointsToPixels: 14 => 18.666666666666668
pointsToPixels: points ^points * self pixelsPerInch / 72.0
but in Athens, i , stupid idiot, completely forgot about that, and use point size directly, to scale up font .. but the point is that this scaling performed in font units (EMs).
so, to actually scale font correctly, i must use same TextStyle pointsToPixels: .. as Freetype package using..
there is one caveat, that if you really want to see exactly , say 16 points sized font on your screen, it is not possible without knowing the display resolution - how many pixels in one inch (hence #pixelsPerInch ). Unfortunately, our VMs don't give us a way to determine DPI of display.. and so, it is always 96 :/
pheww....
fromFreetypeFont: aFont cairoFace: face .....
- fontMatrix scaleBy: aFont pointSize.
+ fontMatrix scaleBy: (TextStyle pointsToPixels: aFont pointSize).
problem solved ... (i hope) :)
-- Best regards, Igor Stasenko.
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
-- Best regards, Igor Stasenko.
On 2 April 2014 14:46, J.F. Rick <self@je77.com> wrote:
Is this supposed to fix the font rendering problem or some other font problem? I tried it and it doesn't seem to help the rendering problem.
send me your image , pls. (and provide doit to reproduce problem, i will try it on my linux box)
Cheers,
Jeff
-- Best regards, Igor Stasenko.
I have followed the discussion from very far. But thank you guys for considering this important font problem. I will offer some beers at esug, I promise :-) Alexandre On Apr 2, 2014, at 7:09 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 2 April 2014 14:46, J.F. Rick <self@je77.com> wrote: Is this supposed to fix the font rendering problem or some other font problem? I tried it and it doesn't seem to help the rendering problem.
send me your image , pls. (and provide doit to reproduce problem, i will try it on my linux box)
Cheers,
Jeff
-- Best regards, Igor Stasenko.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi, On Fri, Mar 28, 2014 at 4:01 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Ookkayy..
First of all, thanks a lot for offering a fix for the font problem! This was a critical issue for Moose.
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!
Yes. They are separate and should be treated separately as you point out :).
- 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).
Good.
- 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. :)
Exactly. However, in this case we made an exception because we had this issue since 1 month, and given that it was blocking for any meaningful visualization, we loaded an older version for Athens in the Moose image just to be able to develop while waiting for the fix in Pharo. - 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..
Great. Thanks again, Doru
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com "Every thing has its own flow"
participants (8)
-
Alexandre Bergel -
Ben Coman -
Blondeau Vincent -
David T. Lewis -
Igor Stasenko -
J.F. Rick -
Pharo4Stef -
Tudor Girba