[ANN] Fix invisible characters in fonts

> Hi all,
>
> from time to time we get invisible characters into our source code,  
> leading to strange compiler errors. It's really hard to spot those  
> blank one-pixel-wide glyphs.
>
> Truetype fonts have a hollow rectangle to indicate missing glyphs.  
> This package patches the StrikeFonts to show a similar hollow  
> rectangle for any non-whitespace character that had a blank glyph:
>
> http://source.impara.de/underscore/FixInvisible-bf.1.mcz
>
> Tested in 3.8 and 3.9, should work in virtually any version.
>
> See attached image for the result.
>
> - Bert -

> Hi bert
>
> I would like to add that in 3.9. Do you think that this is wise/
> wished?
> Because indeed I have always problem with the students with that.
>
> Stef
>
>> Hi all,
>>
>> from time to time we get invisible characters into our source  
>> code, leading to strange compiler errors. It's really hard to spot  
>> those blank one-pixel-wide glyphs.
>>
>> Truetype fonts have a hollow rectangle to indicate missing glyphs.  
>> This package patches the StrikeFonts to show a similar hollow  
>> rectangle for any non-whitespace character that had a blank glyph:
>>
>> http://source.impara.de/underscore/FixInvisible-bf.1.mcz
>>
>> Tested in 3.8 and 3.9, should work in virtually any version.
>>
>> See attached image for the result.
>>
>> - Bert -

> Am 10.04.2006 um 12:19 schrieb Martin Wirblat:
>
>>
>>> What about lf (10)?
>>> I don't know if that Unix-EndOfLine-Character finally entered  
>>> Squeak sources.
>>> But be prepared. -:)
>>
>> Right, especially because #isSeparator knows it already.
>
> No, in Squeak, carriage-return indicates the end of line. The  
> character scanner looks for it to start the next line. It does not  
> for a line-feed char.
>
> If a line-feed is in the source, I rather want to see it. There are  
> some actually in there, and they're hard to spot.
>
> We could install a more descriptive glyph than just a block (think  
> L over F or something), but some visible glyph I do want.
>
> - Bert -
>
>

> Ok so let us know when you think this is ready for inclusion.
>
> Stef
> On 10 avr. 06, at 11:54, Bert Freudenberg wrote:
>
>> Am 10.04.2006 um 12:19 schrieb Martin Wirblat:
>>
>>>
>>>> What about lf (10)?
>>>> I don't know if that Unix-EndOfLine-Character finally entered  
>>>> Squeak sources.
>>>> But be prepared. -:)
>>>
>>> Right, especially because #isSeparator knows it already.
>>
>> No, in Squeak, carriage-return indicates the end of line. The  
>> character scanner looks for it to start the next line. It does not  
>> for a line-feed char.
>>
>> If a line-feed is in the source, I rather want to see it. There  
>> are some actually in there, and they're hard to spot.
>>
>> We could install a more descriptive glyph than just a block (think  
>> L over F or something), but some visible glyph I do want.
>>
>> - Bert -
>>
>>
>

> It is "ready for inclusion" right now. When I wrote "we could" I  
> meant this very optional.
>
> - Bert -
>
> Am 10.04.2006 um 12:22 schrieb stéphane ducasse:
>
>> Ok so let us know when you think this is ready for inclusion.
>>
>> Stef
>> On 10 avr. 06, at 11:54, Bert Freudenberg wrote:
>>
>>> Am 10.04.2006 um 12:19 schrieb Martin Wirblat:
>>>
>>>>
>>>>> What about lf (10)?
>>>>> I don't know if that Unix-EndOfLine-Character finally entered  
>>>>> Squeak sources.
>>>>> But be prepared. -:)
>>>>
>>>> Right, especially because #isSeparator knows it already.
>>>
>>> No, in Squeak, carriage-return indicates the end of line. The  
>>> character scanner looks for it to start the next line. It does  
>>> not for a line-feed char.
>>>
>>> If a line-feed is in the source, I rather want to see it. There  
>>> are some actually in there, and they're hard to spot.
>>>
>>> We could install a more descriptive glyph than just a block  
>>> (think L over F or something), but some visible glyph I do want.
>>>
>>> - Bert -
>>>
>>>
>>
>
>
>
>