- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Small text composition bench

by Igor Stasenko

On 12 October 2013 09:28, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2013/10/12 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > >> So here is the display mini bench: >> >> | text canvas m1 m2 | >> canvas := FormCanvas extent: 569@399 depth: 32. >> >> text := Compiler evaluate: (FileSystem workingDirectory parent parent >> parent / 'text.st' ) readStream contentsOfEntireFile . >> m1 := TextMorph new. >> m1 text: text textStyle: TextStyle default. >> m1 wrapFlag: true. >> m1 extent: 569@9999999. >> MessageTally spyOn: [ 100 timesRepeat: [ >> m1 drawOn: canvas]]. >> m2 := TxTextMorph new. >> m2 layoutStrategy: TxWrapTextStrategy new. >> m2 extent: 569@9999999. >> m2 newTextContents: text. >> MessageTally spyOn: [ 100 timesRepeat: [ >> m2 drawOn: canvas]]. >> >> Squeak revised BitBltDisplayScanner 1077ms / Pharo MultiDisplayScanner >> 1229ms / Pharo TxText 1584ms > > > Interesting how Athens drawing will change picture > i hoping for the better. i did many changes comparing to your original code, and need to do some cleanup. In athens to calculate layout i introduced a special role called "font metrics provider" , which is responsible for calculating dimensions of separate glyphs and advance. Right now it is hardcoded to use CairoFontMetricsProvider, but later it going to be refurbished and merged with CairoFreetypeFontRenderer. So you will be able to obtain one using: fontRenderer := canvas setFont: aFont. or: fontRenderer := aFont glyphRendererOn: surface. and once you got it, you can ask certain things from it: fontRenderer getGlyphWidth: aCharacter fontRenderer fontAscent fontRenderer fontHeight etc but it is not fully organically merged yet, and need more thought what is public API of it to cover the needs of rendering text and/or measuring it. -- Best regards, Igor Stasenko.

Oct. 21, 2013

Re: [Pharo-dev] Character>>#leadingChar

by Henrik Johansen

On Oct 21, 2013, at 11:56 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > My guess is most if not all systems which do support that case, implement a higher level abstraction than "String" to take care of it. â¦ or not :) http://www.unicode.org/faq/vs.html http://www.unicode.org/reports/tr37/ Which means, you can solve the problems caused by Han Unification using standard Unicode. Seems like a lot of fun to implement support for :) Cheers, Henry

Oct. 21, 2013

Re: [Pharo-dev] [Moose-dev] Class AthensCairoSurface missing in Athens Version 2.5?

by Alexandre Bergel

Any update? Cheers, Alexandre On Oct 20, 2013, at 3:27 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 20 October 2013 15:03, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > hi! > > Apparently this class is not present in Version 2.5. > The example is broken because of this apparently: > AthensCairoSurfaceExamples exampleInterop > => error > > Any idea what's going on? > > > Error in Configuration? > I will check loading it in fresh image. > > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- > Best regards, > Igor Stasenko. > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 21, 2013

[update 3.0] #30510

by Marcus Denker

30510 ----- 11955 TabGroupMorph minExtent is broken https://pharo.fogbugz.com/f/cases/11955 11961 non-send method accesses undeclared ivar in PackageTreePacakgeSelection https://pharo.fogbugz.com/f/cases/11961 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-MarcusDenker.577.diff

Oct. 21, 2013

Re: [Pharo-dev] Character>>#leadingChar

by Henrik Johansen

On Oct 21, 2013, at 11:36 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Although from what I understand about Han Unification and from the code, that last point would seem to be the case, but I am not 100% convinced. Most modern systems use Unicode everywhere, so they would all have that problem - a bit hard to believe. We need some feedback from native speakers as well. > > Sven My guess is most if not all systems which do support that case, implement a higher level abstraction than "String" to take care of it. I think you're going to end up waiting a long time if postponing for feedback, other parts that existed solely for a nicer non-western experience has been removed already without any complaints/mentionsâ¦ Might've been since the ImmPlugin only worked on Unix though ;) Cheers, Henry

Oct. 21, 2013

Re: [Pharo-dev] Character>>#leadingChar

by Henrik Johansen

As an added bonus, asInteger / asUnicode / codePoint / charCode / asciiValue would all share the same definition; ^value :) Cheers, Henry P.S. codePoint is currently bugged, it should be ^self asUnicode I'd hardly say the leadingChar-tagged value in potentially different character sets it currently returns meets the ANSI definition of: "Return the encoding value of the receiver in the implementation defined execution character set." On Oct 21, 2013, at 11:18 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Oct 18, 2013, at 6:34 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Hi, >> >> So once again we have an issue with Character>>#leadingChar, see >> >> https://pharo.fogbugz.com/f/cases/6368 >> >> Do we really need this ? >> Any Japanese, Chinese or Korean users willing to comment ? >> >> Thx, >> >> Sven >> > > I'm not any of those, but my short answer would be no. > > As for the long answer: > LeadingChar has too many responsibilities: > - Character set of string > - Font selection (see StrikeFontSet) > - Han unification disambiguation (through the above font selection) > > The conflation of these, and confusion of which leadingChar actually implies, easily leads to bugs, and has done so already. (see Character >> asUnicode as opposed to JapaneseEnvironment >> fromJISX0208String: for example). > I would bet 100â¬ StrikeFontSet no longer works as intended either, that is, being able to display > latin1 glyphs using StrikeFonts. > > Now, here's why I feel those areas are not worth keeping, especially in their current, buggy state: > - Non-unicode character sets > The main reasons for supporting this would be > 1) Size reduction. All Widestrings are 32bits per character, so that's moot. > 2) No need for converting codepoints when using Fonts stored with JISX0208 etc. codePoints . I've yet to see a free/truetype font using anything but Unicode, and since we'd be the creators of any theoretical StrikeFontSet covering other languages, we'd be able to avoid it anyways. > > If, in the future, it'd be desirable to support encodings other than Unicode for internal strings, I feel separate subclasses are a cleaner solution. > > - Font selection / Han unification disambiguation > IMHO, obsoleted by the use of standard TrueType fonts. As long as one does not use StrikeFontSets to display a string, it currently has no benefits. > Yes, one could potentially select different FreeTypeFonts based on it when a run is encountered as well, but the fonts themselves do not contain metadata pertaining to which variant of the glyphs they include, afaik (if they even support them; automatic fallback to another font when current font doesn't cover a glyph would be a higher area of priority) > Even in that case, it could be a property of the current locale instead, while it means you can't display both korean/japanese text in the same image correctly, it'd be a (imho) acceptable tradeoff. > > Cheers, > Henry >

Oct. 21, 2013

Re: [Pharo-dev] Character>>#leadingChar

by Sven Van Caekenberghe

Hi Henry, On 21 Oct 2013, at 11:18, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On Oct 18, 2013, at 6:34 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Hi, >> >> So once again we have an issue with Character>>#leadingChar, see >> >> https://pharo.fogbugz.com/f/cases/6368 >> >> Do we really need this ? >> Any Japanese, Chinese or Korean users willing to comment ? >> >> Thx, >> >> Sven >> > > I'm not any of those, but my short answer would be no. Thanks for the reply and explanation, it seems you confirm what I suspected. > As for the long answer: > LeadingChar has too many responsibilities: > - Character set of string > - Font selection (see StrikeFontSet) > - Han unification disambiguation (through the above font selection) > > The conflation of these, and confusion of which leadingChar actually implies, easily leads to bugs, and has done so already. (see Character >> asUnicode as opposed to JapaneseEnvironment >> fromJISX0208String: for example). > I would bet 100â¬ StrikeFontSet no longer works as intended either, that is, being able to display > latin1 glyphs using StrikeFonts. > > Now, here's why I feel those areas are not worth keeping, especially in their current, buggy state: > - Non-unicode character sets > The main reasons for supporting this would be > 1) Size reduction. All Widestrings are 32bits per character, so that's moot. > 2) No need for converting codepoints when using Fonts stored with JISX0208 etc. codePoints . I've yet to see a free/truetype font using anything but Unicode, and since we'd be the creators of any theoretical StrikeFontSet covering other languages, we'd be able to avoid it anyways. > > If, in the future, it'd be desirable to support encodings other than Unicode for internal strings, I feel separate subclasses are a cleaner solution. > > - Font selection / Han unification disambiguation > IMHO, obsoleted by the use of standard TrueType fonts. As long as one does not use StrikeFontSets to display a string, it currently has no benefits. > Yes, one could potentially select different FreeTypeFonts based on it when a run is encountered as well, but the fonts themselves do not contain metadata pertaining to which variant of the glyphs they include, afaik (if they even support them; automatic fallback to another font when current font doesn't cover a glyph would be a higher area of priority) > Even in that case, it could be a property of the current locale instead, while it means you can't display both korean/japanese text in the same image correctly, it'd be a (imho) acceptable tradeoff. Although from what I understand about Han Unification and from the code, that last point would seem to be the case, but I am not 100% convinced. Most modern systems use Unicode everywhere, so they would all have that problem - a bit hard to believe. We need some feedback from native speakers as well. Sven > Cheers, > Henry >

Oct. 21, 2013

[update 3.0] #30509

by Marcus Denker

30509 ----- 7444 Synchronizing DateAndTime with system OS date and time https://pharo.fogbugz.com/f/cases/7444 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Localization-MarcusDen… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1651.diff

Oct. 21, 2013

Re: [Pharo-dev] Character>>#leadingChar

by Henrik Johansen

On Oct 18, 2013, at 6:34 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > So once again we have an issue with Character>>#leadingChar, see > > https://pharo.fogbugz.com/f/cases/6368 > > Do we really need this ? > Any Japanese, Chinese or Korean users willing to comment ? > > Thx, > > Sven > I'm not any of those, but my short answer would be no. As for the long answer: LeadingChar has too many responsibilities: - Character set of string - Font selection (see StrikeFontSet) - Han unification disambiguation (through the above font selection) The conflation of these, and confusion of which leadingChar actually implies, easily leads to bugs, and has done so already. (see Character >> asUnicode as opposed to JapaneseEnvironment >> fromJISX0208String: for example). I would bet 100â¬ StrikeFontSet no longer works as intended either, that is, being able to display > latin1 glyphs using StrikeFonts. Now, here's why I feel those areas are not worth keeping, especially in their current, buggy state: - Non-unicode character sets The main reasons for supporting this would be 1) Size reduction. All Widestrings are 32bits per character, so that's moot. 2) No need for converting codepoints when using Fonts stored with JISX0208 etc. codePoints . I've yet to see a free/truetype font using anything but Unicode, and since we'd be the creators of any theoretical StrikeFontSet covering other languages, we'd be able to avoid it anyways. If, in the future, it'd be desirable to support encodings other than Unicode for internal strings, I feel separate subclasses are a cleaner solution. - Font selection / Han unification disambiguation IMHO, obsoleted by the use of standard TrueType fonts. As long as one does not use StrikeFontSets to display a string, it currently has no benefits. Yes, one could potentially select different FreeTypeFonts based on it when a run is encountered as well, but the fonts themselves do not contain metadata pertaining to which variant of the glyphs they include, afaik (if they even support them; automatic fallback to another font when current font doesn't cover a glyph would be a higher area of priority) Even in that case, it could be a property of the current locale instead, while it means you can't display both korean/japanese text in the same image correctly, it'd be a (imho) acceptable tradeoff. Cheers, Henry

Oct. 21, 2013

[update 3.0] #30508

by Marcus Denker

30508 ----- 11959 CMD+/ => Comment Selection or Line In PluggableTextMorph (Workspace, Nautilus code pane, ...) https://pharo.fogbugz.com/f/cases/11959 11903 unused MorphicUnknownEvent https://pharo.fogbugz.com/f/cases/11903 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Text-Edition-MarcusDenker.23.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.165… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Strings-MarcusDen…

Oct. 21, 2013