[Resent]
Hi, I sent the following to Squeak beginners and received <silence>. Can anyone help? cheers, Simon ---------- Forwarded Message ---------- Subject: [Newbies] MS Font gives Square box glyphs in TextMorphs: why? Date: Wednesday 06 September 2006 21:39 From: Simon Guest <[hidden email]> To: A friendly place to get answers to even the most basic questions about Squeak <[hidden email]> Hi, I can type text into a TextMorph with a native Squeak font, and pressing return gives me what I desire, i.e. invisible newlines to space out my paragraphs. However, if I change the font to, say, Microsoft Comic Sans (which I installed by dragging and dropping the font file from a Windows Explorer onto the Squeak image), I get square boxes for the carriage return characters. Ugh. Can I make these square boxes invisible with this font, and if so, how? Using Squeak 3.8-6665 on Windows/XP. cheers, Simon _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners ------------------------------------------------------- |
Evaluate: TTFontDescription allInstancesDo: [:each | each blankGlyphForSeparators]. it should have been done automatically... -- Yoshiki |
Where?
Where should this expression should be added? We should fix and incorporate these changes Stef On 9 sept. 06, at 00:00, Yoshiki Ohshima wrote: > > Evaluate: > TTFontDescription allInstancesDo: [:each | each > blankGlyphForSeparators]. > > it should have been done automatically... > > -- Yoshiki > |
Don't. This is changing the font and a workaround at best. (Interpreted)
whitespaces (tab, cr) should never be printed as glyphs - there is something wrong in the printing mechanism (which I need to look at and fix). If you want to help, file a bug instead. Cheers, - Andreas stéphane ducasse wrote: > Where? > Where should this expression should be added? > We should fix and incorporate these changes > > Stef > > On 9 sept. 06, at 00:00, Yoshiki Ohshima wrote: > >> >> Evaluate: >> TTFontDescription allInstancesDo: [:each | each >> blankGlyphForSeparators]. >> >> it should have been done automatically... >> >> -- Yoshiki >> > > > |
I do not know what is the bug.
I was just thinking that we should collect information sent to the list (either fixes or bugs). Stef > Don't. This is changing the font and a workaround at best. > (Interpreted) whitespaces (tab, cr) should never be printed as > glyphs - there is something wrong in the printing mechanism (which > I need to look at and fix). If you want to help, file a bug instead. > > Cheers, > - Andreas > > stéphane ducasse wrote: >> Where? >> Where should this expression should be added? >> We should fix and incorporate these changes >> Stef >> On 9 sept. 06, at 00:00, Yoshiki Ohshima wrote: >>> >>> Evaluate: >>> TTFontDescription allInstancesDo: [:each | each >>> blankGlyphForSeparators]. >>> >>> it should have been done automatically... >>> >>> -- Yoshiki >>> > > |
In reply to this post by Andreas.Raab
The fixes for this bug are in:
http://source.squeakfoundation.org/Graphics/Graphics-ar.40.mcz http://source.squeakfoundation.org/inbox/Multilingual-ar.22.mcz Cheers, - Andreas Andreas Raab wrote: > Don't. This is changing the font and a workaround at best. (Interpreted) > whitespaces (tab, cr) should never be printed as glyphs - there is > something wrong in the printing mechanism (which I need to look at and > fix). If you want to help, file a bug instead. > > Cheers, > - Andreas > > stéphane ducasse wrote: >> Where? >> Where should this expression should be added? >> We should fix and incorporate these changes >> >> Stef >> >> On 9 sept. 06, at 00:00, Yoshiki Ohshima wrote: >> >>> >>> Evaluate: >>> TTFontDescription allInstancesDo: [:each | each >>> blankGlyphForSeparators]. >>> >>> it should have been done automatically... >>> >>> -- Yoshiki >>> >> >> >> > > > |
In reply to this post by Andreas.Raab
Seems thr problem is somewhere in the DisplayScanner classes in that it
prints the glyph regardless of the stop condition. Here's another workaround (which you may not like). In TTCFont glyphInfoOf: aCharacter into: glyphInfoArray "Answer the width of the argument as a character in the receiver." | form | (self hasGlyphOf: aCharacter) ifFalse: [ ^ self fallbackFont glyphInfoOf: aCharacter into: glyphInfoArray. ]. form := self formOf: aCharacter. glyphInfoArray at: 1 put: form; at: 2 put: 0; at: 3 put: ((aCharacter isSeparator and: [aCharacter ~= Character space]) ifTrue: [0] ifFalse: [form width]); at: 4 put: (self ascentOf: aCharacter); at: 5 put: self. ^ glyphInfoArray. > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]]On Behalf Of > Andreas Raab > Sent: 09 September 2006 8:58 AM > To: The general-purpose Squeak developers list > Subject: Re: MS Font gives Square box glyphs in TextMorphs: why? > > > Don't. This is changing the font and a workaround at best. (Interpreted) > whitespaces (tab, cr) should never be printed as glyphs - there is > something wrong in the printing mechanism (which I need to look at and > fix). If you want to help, file a bug instead. > > Cheers, > - Andreas > > stéphane ducasse wrote: > > Where? > > Where should this expression should be added? > > We should fix and incorporate these changes > > > > Stef > > > > On 9 sept. 06, at 00:00, Yoshiki Ohshima wrote: > > > >> > >> Evaluate: > >> TTFontDescription allInstancesDo: [:each | each > >> blankGlyphForSeparators]. > >> > >> it should have been done automatically... > >> > >> -- Yoshiki > >> > > > > > > > > |
In reply to this post by Andreas.Raab
Oops, hadn't read this one at the time of posting!
> -----Original Message----- > From: [hidden email] > [mailto:[hidden email]]On Behalf Of > Andreas Raab > Sent: 09 September 2006 9:24 AM > To: The general-purpose Squeak developers list > Subject: Re: MS Font gives Square box glyphs in TextMorphs: why? > > > The fixes for this bug are in: > > http://source.squeakfoundation.org/Graphics/Graphics-ar.40.mcz > http://source.squeakfoundation.org/inbox/Multilingual-ar.22.mcz > > Cheers, > - Andreas > > Andreas Raab wrote: > > Don't. This is changing the font and a workaround at best. > (Interpreted) > > whitespaces (tab, cr) should never be printed as glyphs - there is > > something wrong in the printing mechanism (which I need to look at and > > fix). If you want to help, file a bug instead. > > > > Cheers, > > - Andreas > > > > stéphane ducasse wrote: > >> Where? > >> Where should this expression should be added? > >> We should fix and incorporate these changes > >> > >> Stef > >> > >> On 9 sept. 06, at 00:00, Yoshiki Ohshima wrote: > >> > >>> > >>> Evaluate: > >>> TTFontDescription allInstancesDo: [:each | each > >>> blankGlyphForSeparators]. > >>> > >>> it should have been done automatically... > >>> > >>> -- Yoshiki > >>> > >> > >> > >> > > > > > > > > |
In reply to this post by Andreas.Raab
Ok
Will be integrated in 3.10. Stef On 9 sept. 06, at 10:24, Andreas Raab wrote: > The fixes for this bug are in: > > http://source.squeakfoundation.org/Graphics/Graphics-ar.40.mcz > http://source.squeakfoundation.org/inbox/Multilingual-ar.22.mcz > > Cheers, > - Andreas > > Andreas Raab wrote: >> Don't. This is changing the font and a workaround at best. >> (Interpreted) whitespaces (tab, cr) should never be printed as >> glyphs - there is something wrong in the printing mechanism (which >> I need to look at and fix). If you want to help, file a bug instead. >> Cheers, >> - Andreas >> stéphane ducasse wrote: >>> Where? >>> Where should this expression should be added? >>> We should fix and incorporate these changes >>> >>> Stef >>> >>> On 9 sept. 06, at 00:00, Yoshiki Ohshima wrote: >>> >>>> >>>> Evaluate: >>>> TTFontDescription allInstancesDo: [:each | each >>>> blankGlyphForSeparators]. >>>> >>>> it should have been done automatically... >>>> >>>> -- Yoshiki >>>> >>> >>> >>> > > |
In reply to this post by Andreas.Raab
Could I also mention that if you are going to print unprintable characters
as a box that you allocate space for that box? Having a box print over a printable character is really a waste and makes no sense. There are perfectly good reasons for including non printable characters in strings, there are a number of protocols that use these characters as separators. Thanks, Ron Teitelbaum > -----Original Message----- > From: [hidden email] [mailto:squeak-dev- > [hidden email]] On Behalf Of Andreas Raab > Sent: Saturday, September 09, 2006 3:58 AM > To: The general-purpose Squeak developers list > Subject: Re: MS Font gives Square box glyphs in TextMorphs: why? > > Don't. This is changing the font and a workaround at best. (Interpreted) > whitespaces (tab, cr) should never be printed as glyphs - there is > something wrong in the printing mechanism (which I need to look at and > fix). If you want to help, file a bug instead. > > Cheers, > - Andreas > > stéphane ducasse wrote: > > Where? > > Where should this expression should be added? > > We should fix and incorporate these changes > > > > Stef > > > > On 9 sept. 06, at 00:00, Yoshiki Ohshima wrote: > > > >> > >> Evaluate: > >> TTFontDescription allInstancesDo: [:each | each > >> blankGlyphForSeparators]. > >> > >> it should have been done automatically... > >> > >> -- Yoshiki > >> > > > > > > > > |
On Mon, 11 Sep 2006 02:24:59 +0200, Ron Teitelbaum wrote:
> Could I also mention that if you are going to print unprintable > characters > as a box that you allocate space for that box? +1 > Having a box print over a > printable character is really a waste and makes no sense. + (1 big) > There are > perfectly good reasons for including non printable characters in strings, > there are a number of protocols that use these characters as separators. /Klaus > Thanks, > > Ron Teitelbaum |
In reply to this post by Ron Teitelbaum
Ron Teitelbaum wrote:
> Could I also mention that if you are going to print unprintable characters > as a box that you allocate space for that box? Having a box print over a > printable character is really a waste and makes no sense. There are > perfectly good reasons for including non printable characters in strings, > there are a number of protocols that use these characters as separators. Absolutely. Do you have an example where a box is printed over a glyph? Cheers, - Andreas |
Andreas,
Ok I went to look at it, and found it to be not as bad as I thought, sorry about that. An example of the problem is: 'Hi ', 1 asCharacter asString, 'there'. I saw it often and assumed incorrectly that it was a larger problem. The problem is with 1 asCharacter. The rest appear to work. Thanks for looking at it, Ron Teitelbaum > -----Original Message----- > From: [hidden email] [mailto:squeak-dev- > [hidden email]] On Behalf Of Andreas Raab > Sent: Monday, September 11, 2006 8:04 AM > To: The general-purpose Squeak developers list > Subject: Re: MS Font gives Square box glyphs in TextMorphs: why? > > Ron Teitelbaum wrote: > > Could I also mention that if you are going to print unprintable > characters > > as a box that you allocate space for that box? Having a box print over > a > > printable character is really a waste and makes no sense. There are > > perfectly good reasons for including non printable characters in > strings, > > there are a number of protocols that use these characters as separators. > > Absolutely. Do you have an example where a box is printed over a glyph? > > Cheers, > - Andreas > |
Ron Teitelbaum wrote:
> I saw it often and assumed incorrectly that it was a larger problem. The > problem is with 1 asCharacter. The rest appear to work. Character value: 1 is used as a marker for embedding morphs and affected by the same problems as tab and cr. If you load the packages that I just announced it will be fixed, too. Cheers, - Andreas |
Andreas,
I loaded your changes. Thank you for the fix it is much better! I see the solution to the 1 asCharacter issue is to remove the printing of the box for this unprintable character. This is not consistent with other non printable characters. It really doesn't matter to me, since the printing or not printing of boxes really has no benefit for me either way, although consistency would be nice. Ron Teitelbaum > From: Andreas Raab > Sent: Monday, September 11, 2006 11:22 AM > > Ron Teitelbaum wrote: > > I saw it often and assumed incorrectly that it was a larger problem. > The > > problem is with 1 asCharacter. The rest appear to work. > > Character value: 1 is used as a marker for embedding morphs and affected > by the same problems as tab and cr. If you load the packages that I just > announced it will be fixed, too. > > Cheers, > - Andreas > |
On 11-Sep-06, at 9:37 AM, Ron Teitelbaum wrote: > non printable characters. It really doesn't matter to me, since the > printing or not printing of boxes really has no benefit for me > either way, > although consistency would be nice. Actually I think it could well be very beneficial to see unprintable characters via some form of boxing. Consider copying and pasting a bit of apparently innocuous text to some other application, whether inside Squeak or outside. If you have a non-printable hidden in there but don't know it (because it shows nothing) then you may well get strange results, depending on how the recipient application treats, say, ctl-M. If we want applications able to filter out undesirable characters then we should write filters to do the filtering. Pretending to do filtering by ignoring the characters at display rendering time is a bit like relying on obscurity for your security. It works sometimes and fails horribly at others. Often without you realising. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: RC: Rewind Core |
In reply to this post by Ron Teitelbaum
Ron Teitelbaum wrote:
> I see the solution to the 1 asCharacter issue is to remove the printing of > the box for this unprintable character. This is not consistent with other > non printable characters. It is consistent. Like I wrote before, Character value: 1 is used to indicate a variable space for displaying an embedded morph, just like Character value: 9 is used to indicate a tab space and Character value: 13 is used to indicate a line break. All of these are interpreted white space characters, for none of which we want to see a glyph. Cheers, - Andreas |
In reply to this post by timrowledge
tim Rowledge wrote:
> On 11-Sep-06, at 9:37 AM, Ron Teitelbaum wrote: >> non printable characters. It really doesn't matter to me, since the >> printing or not printing of boxes really has no benefit for me either >> way, although consistency would be nice. > Actually I think it could well be very beneficial to see unprintable > characters via some form of boxing. Consider copying and pasting a bit > of apparently innocuous text to some other application, whether inside > Squeak or outside. If you have a non-printable hidden in there but don't > know it (because it shows nothing) then you may well get strange > results, depending on how the recipient application treats, say, ctl-M. I think you are a little bit behind the times here. What you are describing is *exactly* what happens. > If we want applications able to filter out undesirable characters then > we should write filters to do the filtering. Pretending to do filtering > by ignoring the characters at display rendering time is a bit like > relying on obscurity for your security. It works sometimes and fails > horribly at others. Often without you realising. Ditto. What you are describing is *exactly* what happens. Cheers, - Andreas |
In reply to this post by Andreas.Raab
A Tab and a CR are not unprintable characters and should not be indicated
with a box. 1 is different in that respect. 1 may be a printable character in Squeak, as you have explained, but it is not in other places. I understand your explanation and I'm fine with leaving it as is. Ron > From: Andreas Raab > Sent: Monday, September 11, 2006 2:06 PM > > Ron Teitelbaum wrote: > > I see the solution to the 1 asCharacter issue is to remove the printing > of > > the box for this unprintable character. This is not consistent with > other > > non printable characters. > > It is consistent. Like I wrote before, Character value: 1 is used to > indicate a variable space for displaying an embedded morph, just like > Character value: 9 is used to indicate a tab space and Character value: > 13 is used to indicate a line break. All of these are interpreted white > space characters, for none of which we want to see a glyph. > > Cheers, > - Andreas > > |
In reply to this post by Andreas.Raab
On 11-Sep-06, at 11:08 AM, Andreas Raab wrote: > tim Rowledge wrote: >> On 11-Sep-06, at 9:37 AM, Ron Teitelbaum wrote: >>> non printable characters. It really doesn't matter to me, since the >>> printing or not printing of boxes really has no benefit for me >>> either way, although consistency would be nice. >> Actually I think it could well be very beneficial to see >> unprintable characters via some form of boxing. Consider copying >> and pasting a bit of apparently innocuous text to some other >> application, whether inside Squeak or outside. If you have a non- >> printable hidden in there but don't know it (because it shows >> nothing) then you may well get strange results, depending on how >> the recipient application treats, say, ctl-M. > > I think you are a little bit behind the times here. What you are > describing is *exactly* what happens. > >> If we want applications able to filter out undesirable characters >> then we should write filters to do the filtering. Pretending to do >> filtering by ignoring the characters at display rendering time is >> a bit like relying on obscurity for your security. It works >> sometimes and fails horribly at others. Often without you realising. > > Ditto. What you are describing is *exactly* what happens. So it was a perfectly sensible explanation to help Ron, wasn't it. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- If what you don't know can't hurt you, she's practically invulnerable. |
Free forum by Nabble | Edit this page |