Mantis Bugtracker
  

Viewing Issue Advanced Details Jump to Notes ] View Simple ] 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 Platform
Status assigned   OS
Projection none   OS Version
ETA none Fixed in Version Product Version
  Product Build
Summary 0001372: Fonts have invisible characters
Description Try "(0 to: 255) asByteArray asString" - there are many blank glyphs
Steps To Reproduce
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