Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0001372 [Squeak] TrueType minor always 06-23-05 17:20 09-30-13 23:22
Reporter bert View Status public  
Assigned To tim
Priority normal Resolution open  
Status assigned   Product Version
Summary 0001372: Fonts have invisible characters
Description Try "(0 to: 255) asByteArray asString" - there are many blank glyphs
Additional Information
Attached Files

- Relationships
related to 0001342assigned tim Support for typographic punctuation is gone 
related to 0001650closed tim [BUG] CharacterScanner primitive is broken; char scanning generally in a mess 

- Notes
(0001676 - 670 - 670 - 670 - 670 - 670 - 670)
KenCausey
06-23-05 18:10

I tried this in 3.6, 3.8, and 3.9 and I guess I see what you mean in terms of there always being some ASCII characters that have no glyph, generally those that don't normally have a visual representation. Exactly which ones those are vary somewhat from image to image and in some cases some of those characters have a glyph which is an empty box. Are you just suggesting that that should be more consistently the case? That every character have some glyph even if it is just a box or other character representing the fact that character has no visual representation? I don't think you would want that to be true in many cases though, for example: \n, \r, \f, \t, \b.
 
(0001677 - 415 - 415 - 415 - 415 - 415 - 415)
bert
06-23-05 19:19

Yes I'd like to have at least an outlined box for each glyph. Even for those CRs, LFs etc, because normally these are not rendered - the character scanner advances the position instead. It still happens in some circumstances to get a control character into your string, like I pressed enter and got a character of value 3 in the sourcecode and the compiler rightfully complains - but you don't *see* anything wrong.
 
(0001712 - 198 - 210 - 210 - 210 - 210 - 210)
masm
07-02-05 02:47

Unprintable characters trouble the compiler.
Some unprintable characters are not 'seen' as blank spaces and when adjacent
to a token, like a selector, they become part of it. This is hard to spot.
 
(0001713 - 287 - 287 - 287 - 287 - 287 - 287)
bert
07-02-05 11:51

masm: That is indeed one of the problems. However, there is one legitimate blank character (char value 160), which is the non-breakable space. Not sure how to deal with that. As it happens, Apple Mail uses that character for indentation, so if I copy code from a Mail it won't compile :(
 
(0002562 - 184 - 196 - 196 - 292 - 292 - 292)
hitoro
08-28-05 12:58

It looks like the issue I reported (0001342).

Some glyphs don't have a representation while they should. Check the typographic glyphs; most are gone (). I really miss them.
 

- Issue History
Date Modified Username Field Change
06-23-05 17:20 bert New Issue
06-23-05 18:06 KenCausey Assigned To KenCausey =>
06-23-05 18:06 KenCausey Category Any => Graphics
06-23-05 18:06 KenCausey Status assigned => new
06-23-05 18:10 KenCausey Note Added: 0001676
06-23-05 19:19 bert Note Added: 0001677
07-02-05 02:47 masm Note Added: 0001712
07-02-05 11:51 bert Note Added: 0001713
08-28-05 12:58 hitoro Note Added: 0002562
10-27-05 10:57 andreas Category Graphics => Fonts
10-27-05 18:58 KenCausey Relationship added related to 0001342
09-30-13 23:22 tim Status new => assigned
09-30-13 23:22 tim Assigned To  => tim
09-30-13 23:23 tim Relationship added related to 0001650


Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
67 total queries executed.
46 unique queries executed.
Powered by Mantis Bugtracker