February 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] athens font rendering and subpixel antialiasing

by Ben Coman

On Mon, Feb 2, 2015 at 8:06 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > Ok, the best I could do: > > Sadly, it only works because I changed the default lcd_filter from cairo. > in cairo 1.7. was a public API for the lcd_filter. > since 1.8 this API is private again (the code for the different filter > settings is still there). > In trying to learn some background info, this found article [1] seems good, from which I learn: * Freely scalable it must be free from character drift. I guess this is what we want ? * Three main types of font rendering: * Hinting trades accuracy for consistency, and as a consequence of this, hinted text _accumulates character drift_ with hinted glyphs, often possessing different metrics to their un-hinted counterparts. So I guess we don't use hinting, which implies not freely scalable ? * Anti-aliasing results in output which is accurate but blurred, trading contrast for consistency and accuracy. * Sub-pixel-rendering exploits the physical geometry of LCD screens to increase the horizontal resolution of the device. Needs to be filtered to avoid color fringing and is incompatible with aggressive hinting strategies. * Sub-pixel-positioning is a generalisation of anti-aliasing and/or sub-pixel-rendering to allow for more accurate glyph placement, and is incompatible with aggressive hinting strategies. That article [1] advises: * For sub-pixel-rendering to function correctly it is necessary to enable the patent encumbered LCD filtering API. Many distributions, including Debian, do this already and is generally not a problem. * Versions of Cairo before the 1.10 release use their own intra-pixel filter. As of 2009 there are two sets of patches available that update legacy releases of Cairo to use an FIR inter-pixel filter. The first set pre-dates the filtering interface in FreeType and uses a custom FIR filter with the coefficients outlined in Gib98. The second set of patches, by David Turner, take advantage of the FreeType filtering interface. * It is recommended that distributions upgrade to Cairo 1.10 where at all possible. Here [2] is a post on that. So btw, what version of Cario are we using? I see latest is version 1.12.18. [1] https://freddie.witherden.org/pages/font-rasterisation/#spo07 [2] http://lists.cairographics.org/archives/cairo/2010-January/018859.html > You can choose between > FT_LCD_FILTER_NONE > FT_LCD_FILTER_LEGACY > FT_LCD_FILTER_LIGHT > FT_LCD_FILTER_DEFAULT > > the default is FT_LCD_FILTER_LEGACY > but for this (so far, the best) result I used > FT_LCD_FILTER_DEFAULT > But there is no public API for this function anymore, so I had to > change the code. > > > We have to discuss how we proceed. > > The problems: > font rendering looks ugly ( at least for small font size like for menus, > lists and codepanes) > font rendering looks different on windows and linux > > possible solutions: > change build options for Freetype on Windos (enable > FT_CONFIG_OPTION_SUBPIXEL_RENDERING, potential patent infringement?) > change default filter (patching cairo source) > > or we leave everything as it is. > I do not know, and I'm starting to lose all interest. > > > nicolai > > > > 2015-02-01 19:38 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > >> **** patents! >> >> Hours, and days digging in the code for font rendering with cairo. >> I tried to find out why this "colored" subpixel antialising is not >> working although >> all option settings are set (in cairo) and in the source code of cairo >> the FT_SetLCDFilter >> call is really used! But the output does is just the same as with >> CAIRO_ANTIALIAS_GRAY, >> >> ... until I found THIS in the freetype config: >> >> /* Uncomment the line below if you want to activate sub-pixel rendering */ >> /* (a.k.a. LCD rendering, or ClearType) in this build of the library. */ >> /* */ >> /* Note that this feature is covered by several Microsoft patents */ >> /* and should not be activated in any default build of the library. */ >> /* */ >> /* This macro has no impact on the FreeType API, only on its */ >> /* _implementation_. For example, using FT_RENDER_MODE_LCD when calling */ >> /* FT_Render_Glyph still generates a bitmap that is 3 times wider than */ >> /* the original size in case this macro isn't defined; however, each */ >> /* triplet of subpixels has R=G=B. */ >> >> >> >> >> ARGH! >> >> It still does not look as good as with the pharos freetypeplugin, but AT >> LEAST it looks >> equally on windows and linux , yeh. >> >> >> attached are three screenshots comparing >> the different athens drawings with the freetypeplugin >> athens on linux vs ftplugin >> athens on windows vs ftplugin >> athens on windows with enabled FT_CONFIG_SUBPIXEL_RENDERING vs ftplugin >> >> >> >> >> >> >> >> >> >> >> >> 2015-01-31 10:18 GMT+01:00 stepharo <stepharo(a)free.fr>: >> >>> >>> In athens, there are "hints" you can set. >>> (CairoFontOptions/hintMetricsOff/hintMetricsOn/hintStyleFull ....) >>> I played a bit with different settings. Changing this settings change >>> the output, but I can not get it to look >>> like with the freetype plugin. I understand that this can not look >>> equally, because the FreeTypePlugin and caire work differently, >>> but the athens result looks bad compared with the other one. >>> >>> >>> >>>> - Pixel fitting. (The aliasing going on at the top of characters) Put >>>> Hinting: None in FreeType advanced features, and you will probably see >>>> something similar to the Athens rendering. >>>> >>> >>> Yes, we can change the freetypeplugin setting and cairofontoption >>> setting to make the output look equally - ugly :) >>> >>> >>> Nicolai >>> >>> Igor explained to me that FreeType offers a degenerated mode that when >>> the font does have the information for bold, kerning,.... >>> computes a "guessed and approximated" default. Cairo does not offer this >>> api else Athens would use it. >>> So what would be interesting is to test using font having all the >>> information to see if Cairo display well the fonts. >>> >>> Stef >>> >> >> >

Feb. 2, 2015

Re: [Pharo-dev] athens font rendering and subpixel antialiasing

by phil＠highoctane.be

On Mon, Feb 2, 2015 at 10:51 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 02 Feb 2015, at 01:06, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > I do not know, and I'm starting to lose all interest. > > Nicolai, > > Please don't give up. > Yeah, don't. You rock. > > You are doing great work and we are all *very* impressed with your > attitude/drive/motivation, especially since you are covering such a wide > range of subjects. I know that the hard thing right now is that you do not > find enough sparring partners (that goes for others tackling different > issues as well). > Sven > Phil

Feb. 2, 2015

Re: [Pharo-dev] athens font rendering and subpixel antialiasing

by Igor Stasenko

Another idea would be to create a freetype face instance by directly calling freetype library, avoiding any interference with freetype plugin and in-image code for it etc. Because i suspecting there's something with the way it handles options/font matrix etc, that at some point got overridden, while cairo expecting it to be unchanged. -- Best regards, Igor Stasenko.

Feb. 2, 2015

Re: [Pharo-dev] athens font rendering and subpixel antialiasing

by Sven Van Caekenberghe

> On 02 Feb 2015, at 01:06, Nicolai Hess <nicolaihess(a)web.de> wrote: > > I do not know, and I'm starting to lose all interest. Nicolai, Please don't give up. You are doing great work and we are all *very* impressed with your attitude/drive/motivation, especially since you are covering such a wide range of subjects. I know that the hard thing right now is that you do not find enough sparring partners (that goes for others tackling different issues as well). Sven

Feb. 2, 2015

Re: [Pharo-dev] athens font rendering and subpixel antialiasing

by Igor Stasenko

On 2 February 2015 at 01:06, Nicolai Hess <nicolaihess(a)web.de> wrote: > Ok, the best I could do: > > Sadly, it only works because I changed the default lcd_filter from cairo. > in cairo 1.7. was a public API for the lcd_filter. > since 1.8 this API is private again (the code for the different filter > settings is still there). > You can choose between > FT_LCD_FILTER_NONE > FT_LCD_FILTER_LEGACY > FT_LCD_FILTER_LIGHT > FT_LCD_FILTER_DEFAULT > > the default is FT_LCD_FILTER_LEGACY > but for this (so far, the best) result I used > FT_LCD_FILTER_DEFAULT > But there is no public API for this function anymore, so I had to > change the code. > > > We have to discuss how we proceed. > > The problems: > font rendering looks ugly ( at least for small font size like for menus, > lists and codepanes) > font rendering looks different on windows and linux > > possible solutions: > change build options for Freetype on Windos (enable > FT_CONFIG_OPTION_SUBPIXEL_RENDERING, potential patent infringement?) > change default filter (patching cairo source) > > or we leave everything as it is. > I do not know, and I'm starting to lose all interest. > I guess, to understand what happens, best would be to write a small C app, that does the rendering.. and see what goes where. Something doesn't works there.. but i was unable to figure what or why. I doubt that changing freetype library build settings is right way to deal with issue, because a) both cairo/freetype used on linux out of the box b) many many apps, using these libs to render with subpixel quality. -- Best regards, Igor Stasenko.

Feb. 2, 2015

WhatsUp from: 2015-02-02 until: 2015-02-15

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2015-02-15 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

Feb. 2, 2015

Re: [Pharo-dev] Proposal for LiteralArray class

by Eliot Miranda

On Sun, Feb 1, 2015 at 3:39 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-02-01 10:52 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >> >> Looking into Image locking problems [1] caused by a recursive array such >> as this... >> >> literalArray := #( 1 2 3 ). >> literalArray at: 3 put: literalArray. >> >> I find that "literalArray printString" locks the image due to >> Array>>printOn: use of the recursive #shouldBePrintedAsLiteral method. Now >> its implementation is identical to #isLiteral and indeed "literalArray >> isLiteral" also locks the Image. So comparing implementors of #isLiteral... >> >> >> > > Squeak uses a Set to store all visited elements for > shouldBePrintedAsLiteral and this protects against the recursive loop. > > shouldBePrintedAsLiteralVisiting: aSet > self class == Array ifFalse: > [^false]. > (aSet includes: self) ifTrue: > [^false]. > aSet add: self. > ^self allSatisfy: [:each | each shouldBePrintedAsLiteralVisiting: aSet] > > > isn't there a common pattern to handle this kind of potential endless > recursion? > At Cadence we fixed it thus: Object>>shouldBePrintedAsLiteral ^self isLiteral Array>>shouldBePrintedAsLiteral ^self class == Array and: [self shouldBePrintedAsLiteralVisiting: (IdentitySet new: 8)] Object>>shouldBePrintedAsLiteralVisiting: aSet ^self isLiteral Array>>shouldBePrintedAsLiteralVisiting: aSet self class == Array ifFalse: [^false]. (aSet includes: self) ifTrue: [^false]. aSet add: self. ^self allSatisfy: [:each | each shouldBePrintedAsLiteralVisiting: aSet] Object>>isLiteral ^false >> Boolean>>isLiteral ^true >> Character>>isLiteral ^true >> Integer>>isLiteral ^true >> String>>isLiteral ^true >> UndefinedObject>>isLiteral ^true >> >> ByteArray>>isLiteral ^self class == ByteArray >> Float>>isLiteral ^self isFinite "^(self - self) = 0.0" >> ScaledDecimal>>isLiteral ^denominator = 1 or: [(10 raisedTo: >> scale)\\denominator = 0] >> >> Array>>isLiteral ^self class == Array and: [self allSatisfy: [:each | >> each isLiteral]] >> >> ...I find most are very basic (might even say deterministic), with the >> recursion of Array>>isLiteral seeming an annomaly. Also, the big IF >> condition in Array>>printOn: smells like a design decision being made at >> runtime (Valloud AMCOS p12). >> >> Array>>printOn: aStream >> self shouldBePrintedAsLiteral ifTrue: [self printAsLiteralFormOn: >> aStream. ^ self]. >> self isSelfEvaluating ifTrue: [self printAsSelfEvaluatingFormOn: aStream. >> ^ self]. >> super printOn: aStream >> >> Flipping between two printString formats seems like selecting between two >> class types. Indeed, if we had a LiteralArray class, there would be no need >> for its printOn: to recursively search to determine its form, thus allowing >> #printStringLimitedTo: to do its thing to protect against infinite >> recursion. >> >> Also, instead of a recursive Array>>isLiteral we'd have something like >> LiteralArray>>isLiteral ^true >> Array>>isLiteral ^false >> which seems to align much better with the pattern of the other #isLiteral >> implementors. >> >> I notice there is both RBArrayNode and RBLiteralArrayNode. >> >> So what are the wider concerns that might apply? >> (In particular, I'm not sure how the #isSelfEvaluating (which is also >> recursive) fits into the big picture) >> >> cheers -ben >> >> [1] https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg25156.html >> > > -- best, Eliot

Feb. 2, 2015

Re: [Pharo-dev] athens font rendering and subpixel antialiasing

by Nicolai Hess

Ok, the best I could do: Sadly, it only works because I changed the default lcd_filter from cairo. in cairo 1.7. was a public API for the lcd_filter. since 1.8 this API is private again (the code for the different filter settings is still there). You can choose between FT_LCD_FILTER_NONE FT_LCD_FILTER_LEGACY FT_LCD_FILTER_LIGHT FT_LCD_FILTER_DEFAULT the default is FT_LCD_FILTER_LEGACY but for this (so far, the best) result I used FT_LCD_FILTER_DEFAULT But there is no public API for this function anymore, so I had to change the code. We have to discuss how we proceed. The problems: font rendering looks ugly ( at least for small font size like for menus, lists and codepanes) font rendering looks different on windows and linux possible solutions: change build options for Freetype on Windos (enable FT_CONFIG_OPTION_SUBPIXEL_RENDERING, potential patent infringement?) change default filter (patching cairo source) or we leave everything as it is. I do not know, and I'm starting to lose all interest. nicolai 2015-02-01 19:38 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > **** patents! > > Hours, and days digging in the code for font rendering with cairo. > I tried to find out why this "colored" subpixel antialising is not working > although > all option settings are set (in cairo) and in the source code of cairo the > FT_SetLCDFilter > call is really used! But the output does is just the same as with > CAIRO_ANTIALIAS_GRAY, > > ... until I found THIS in the freetype config: > > /* Uncomment the line below if you want to activate sub-pixel rendering */ > /* (a.k.a. LCD rendering, or ClearType) in this build of the library. */ > /* */ > /* Note that this feature is covered by several Microsoft patents */ > /* and should not be activated in any default build of the library. */ > /* */ > /* This macro has no impact on the FreeType API, only on its */ > /* _implementation_. For example, using FT_RENDER_MODE_LCD when calling */ > /* FT_Render_Glyph still generates a bitmap that is 3 times wider than */ > /* the original size in case this macro isn't defined; however, each */ > /* triplet of subpixels has R=G=B. */ > > > > > ARGH! > > It still does not look as good as with the pharos freetypeplugin, but AT > LEAST it looks > equally on windows and linux , yeh. > > > attached are three screenshots comparing > the different athens drawings with the freetypeplugin > athens on linux vs ftplugin > athens on windows vs ftplugin > athens on windows with enabled FT_CONFIG_SUBPIXEL_RENDERING vs ftplugin > > > > > > > > > > > > 2015-01-31 10:18 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> >> In athens, there are "hints" you can set. >> (CairoFontOptions/hintMetricsOff/hintMetricsOn/hintStyleFull ....) >> I played a bit with different settings. Changing this settings change >> the output, but I can not get it to look >> like with the freetype plugin. I understand that this can not look >> equally, because the FreeTypePlugin and caire work differently, >> but the athens result looks bad compared with the other one. >> >> >> >>> - Pixel fitting. (The aliasing going on at the top of characters) Put >>> Hinting: None in FreeType advanced features, and you will probably see >>> something similar to the Athens rendering. >>> >> >> Yes, we can change the freetypeplugin setting and cairofontoption >> setting to make the output look equally - ugly :) >> >> >> Nicolai >> >> Igor explained to me that FreeType offers a degenerated mode that when >> the font does have the information for bold, kerning,.... >> computes a "guessed and approximated" default. Cairo does not offer this >> api else Athens would use it. >> So what would be interesting is to test using font having all the >> information to see if Cairo display well the fonts. >> >> Stef >> > >

Feb. 2, 2015

Re: [Pharo-dev] athens font rendering and subpixel antialiasing

by Nicolai Hess

**** patents! Hours, and days digging in the code for font rendering with cairo. I tried to find out why this "colored" subpixel antialising is not working although all option settings are set (in cairo) and in the source code of cairo the FT_SetLCDFilter call is really used! But the output does is just the same as with CAIRO_ANTIALIAS_GRAY, ... until I found THIS in the freetype config: /* Uncomment the line below if you want to activate sub-pixel rendering */ /* (a.k.a. LCD rendering, or ClearType) in this build of the library. */ /* */ /* Note that this feature is covered by several Microsoft patents */ /* and should not be activated in any default build of the library. */ /* */ /* This macro has no impact on the FreeType API, only on its */ /* _implementation_. For example, using FT_RENDER_MODE_LCD when calling */ /* FT_Render_Glyph still generates a bitmap that is 3 times wider than */ /* the original size in case this macro isn't defined; however, each */ /* triplet of subpixels has R=G=B. */ ARGH! It still does not look as good as with the pharos freetypeplugin, but AT LEAST it looks equally on windows and linux , yeh. attached are three screenshots comparing the different athens drawings with the freetypeplugin athens on linux vs ftplugin athens on windows vs ftplugin athens on windows with enabled FT_CONFIG_SUBPIXEL_RENDERING vs ftplugin 2015-01-31 10:18 GMT+01:00 stepharo <stepharo(a)free.fr>: > > In athens, there are "hints" you can set. > (CairoFontOptions/hintMetricsOff/hintMetricsOn/hintStyleFull ....) > I played a bit with different settings. Changing this settings change > the output, but I can not get it to look > like with the freetype plugin. I understand that this can not look > equally, because the FreeTypePlugin and caire work differently, > but the athens result looks bad compared with the other one. > > > >> - Pixel fitting. (The aliasing going on at the top of characters) Put >> Hinting: None in FreeType advanced features, and you will probably see >> something similar to the Athens rendering. >> > > Yes, we can change the freetypeplugin setting and cairofontoption > setting to make the output look equally - ugly :) > > > Nicolai > > Igor explained to me that FreeType offers a degenerated mode that when the > font does have the information for bold, kerning,.... > computes a "guessed and approximated" default. Cairo does not offer this > api else Athens would use it. > So what would be interesting is to test using font having all the > information to see if Cairo display well the fonts. > > Stef >

Feb. 1, 2015

Re: [Pharo-dev] Overwrite repository in symbolic version

by Thierry Goubier

Hi Uko, If I understand your need correctly, I would say yes : you can add a spec repository: anUrl inside the version and this should override the repository inside the baseline method. If you're ready to try some of the new stuff pushed in Metacello by Dale, I would suggest that you create a BaselineOfYourProject inside your branch and write a configuration which refer to the baseline; there, just changing the url to point to your branch would make it work. inside the version method, for example: (gitfiletree url) spec blessing: #development; author: 'ThierryGoubier'; baseline: 'AltBrowser' with: [ spec repository: 'gitfiletree:// github.com/ThierryGoubier/AltBrowser.git?branch=pharo4.0' ]; import: 'AltBrowser' (It's also quite convenient to be able to work with metacello scripts which are as short as loading the configuration in the first place: Metacello new baseline: 'AltBrowser'; repository: 'gitfiletree://github.com/ThierryGoubier/AltBrowser:pharo4.0 '; load And you can then customize your dependencies per branches, by modifying the BaselineOf in each. Thierry 2015-02-01 16:21 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi, > > I'm using git for versioning, and usually I just work with master branch. > Now I have created another branch, can I create at least temporal symbolic > version that will work on a current baseline, but will use different > "repository" and so other branch? Or is there another good way to handle > branches? > > Uko >

Feb. 1, 2015