Closed Bug 367639 Opened 18 years ago Closed 17 years ago

Poor rendering of scientific text with Unicode characters.

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: xanthian, Unassigned)

References

(
URL
)

Details

Attachments

(3 files)

third line, first indented paragraph both show errors
(deleted), image/png
Details
Screen shot - 1.yours 2.Shift_JIS/MS-Mincho, 3.iso-8859-1/Times New Roman
(deleted), image/png
Details
Screen shot - problem is affected by window width
(deleted), image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070120 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070120 SeaMonkey/1.5a

[This may well be a duplicate or a sibling of bug 324857; I don't
understand the terminology in use there to differentiate the two
situations.]

The discussion of astronomy at the indicated URL renders quite
acceptably in Internet Explorer 6.x, except for some "missing
glyph" boxes, but ends up a pied mess in the current SeaMonkey
nightly build. Problems include lost text, text overprints,
unrequested font size shifts, among others. This looks like a
good test case for debugging math-intense text, so I thought I'd
make it a separate bug, just to call this URL to debuggers'
attention.

xanthian.


Reproducible: Always

Steps to Reproduce:
1. Open URL
2. Observe dozens of instances of pied text rendering.
3.
Actual Results:  
Text is rendered in ways that make much of it
unreadable.

Expected Results:  
Correctly rendered text.

This is a 1998 document, so it probably isn't pushing
today's state of the Math symbols / Unicode symbols art
very hard, and SeaMonkey should be doing a lot better
job of rendering it than in the case it does.

[I'm NOT copying the "critical" classification from bug
324857; "major" seems more correct.]

xanthian.
It is worth calling to developer's attention, though
I'm not sure if this is a separate bug, that the text
which is rendered oversized creates text lines which
exceed the window width, yet there is no bottom slider
bar offered, when reading the text at the subject URL.

This seems to indicate the the "need for a slider bar"
calculation is misplaced, and should follow the "how
far right are pixels being rendered" point.

Developers are welcome to make this a separate bug.

xanthian.

The page at the url given looks fine to me. There is no garbled text.
--
The page or server specifies no encoding.
My browser is set to use unicode as the default. Try changing the character encoding of the page (View menu --> character encoding) to utf-8, if the page was not already displayed using that encoding. Although, it also displays fine for me using 'western' encoding.

---

Or it might just be your fonts. Try increasing the font size using the + key on the keyboard.

--

Oh, I see one thing: 
it didn't at first display ∼ on seamonkey 1.1 at first.

However, later it did display it for me. I browsed to another page on the web (this one --> http://www.cookwood.com/html/extras/entities.html ), and then back, and then the tilde character was displayed rather than a question mark at the place where the document uses & sim ;

 I think this is bug affecting mozilla products in how it finds fonts to display certain entities. (I've posted here before this happening with tibetan text and armenian text, and about the weird work-around).

--
if you still see the problem, screen shots highlighting some affected areas would be helpful. Otherwise we are guessing a what areas are affected and what you see.

> [I'm NOT copying the "critical" classification from bug
> 324857; "major" seems more correct.]

if I read bug 324857 correctly, it's not that characters are not rendering, but rather poor display characteristics.


renders fine (and same) for me  UTF-8 and ISO-8859-1

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070330 SeaMonkey/1.5a
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 XpcomViewer/0.8.9
Version: unspecified → Trunk
(In reply to comment #4)
> if you still see the problem, screen shots highlighting some affected areas
> would be helpful. Otherwise we are guessing a what areas are affected and what
> you see.

Give me strength.

Did you _look_? The problems rather leap off the screen.

Okay, the attachment is from the originally URLed problem
example site. The third line shifts incorrectly to uppercase,
then its size is miscomputed, so it runs off the right side
of the window rather than wrapping at a place appropriate to
how it was (mis)rendered.

The first indented paragraph, numbered "1.", about 78% down
the page, shows text that overstrikes itself.

Looking through the entire rendered document, you'll see many
many similar errors, but this example should at least help
you decide _to_ look.

xanthian.
Sorry, should have mentioned that the example in comment 5
was captured from the MS-Windows nightly build of 2007051309.

xanthian.

(In reply to comment #5)
> third line, first indented paragraph both show errors
Problem is recreated with Firefox trunk(2007/5/13 build,Japanese MS Win-XP SP2).
 1.Top window, Your result
 2.Middle window
   Character encoding : Shift_JIS(by auto-detect)
   Used font : Japanese, Proportional=Sans-serf => MS-Gothic
              (Same when Proportional=Serif     => MS-Mincho)
   => No problem
 3.Bottom window
   Character encoding : iso-8859-1
   Used font : Western, Proportional=Serif => Times New Romen
   => Problem is observed
Looks to be font dependent problem.
Both window is display under iso-8859-1,Western,Proportional=Serif,Serif=Times New Roman,Sans-Serif=Courier New,Monospce=Courier.
 (a) Left  window : no problem in the section (corrupted in other place)
 (b) Right window : problem in the section (corrupted too in different place)
In right window, Courier(monospace) looks to be used in corrupted part. It seems that character width is calculated with Times New Roman(proportional) but font really used to render is Courier(monospace). Possibly font selection/switch problem.
(In reply to comment #5
> 
> Give me strength.
> 
> Did you _look_? The problems rather leap off the screen.
> ...
> Looking through the entire rendered document, you'll see many
> many similar errors, but this example should at least help
> you decide _to_ look.

quoting from comment 4 "renders fine (and same) for me UTF-8 and ISO-8859-1" states it fairly clearly

inclined to agree with font related
Bug 332649 possibly has relation to this bug, although I think not DUP. 
Test case of Bug 332649 is text overlap case after font switch to render special character(not included in font).
By the way, Kent Paul Dolan(bug opener), could you change summary to appropriate one, for ease of search and ease of understanding problem, please.
(In reply to comment #11)

> By the way, Kent Paul Dolan(bug opener), could you
> change summary to appropriate one, for ease of
> search and ease of understanding problem, please.

I'm afraid there are so _many_ symptoms [text
rendered the wrong size, lines running out of the
window, text overstruck, characters misrendered,
characters missing but not marked with the missing
character glyph, math "penalty text" set pied,
problems seen varying with window width], I don't
have anything better than "poor rendering" to offer,
but it won't hurt my feelings if someone else who
sees more accurately what is going wrong changes the
summary, that seems to happen here fairly often.

By the way, comment #7 confirmed the bug exists, and
calling it "font related" is inaccurate, it is "font
handling related", since the same text displays much
more accurately in Internet Explorer, with the same
resource of fonts from which to choose and from
which to render the page.

The bug should thus no longer be marked
"UNCONFIRMED", but changing that is outside my
purvue, and to what to change it isn't in my
knowledge base.

(In reply to comment #7)

The text was _not_ "Shift JIS" encoded, so if
autodetection found that, autodetection needs
repair.

Nevertheless, its quite possible that fonts
supporting "Shift JIS" are equipped with a richer
subset of Unicode than are fonts supporting
iso-8859-1 (if that makes sense), explaining the
better rendering.

I'm purely guessing here, but since IE does a better
job while introducing lots of "missing glyph"
rectangles, the issue may be that SeaMonkey, which
isn't showing (as many?) missing glyph symbols, is
instead trying to use glyphs that don't exist in the
chosen font, through some misinterpretation of the
font's glyph index, processing non-font data as if
it were font data, and wandering far into the weeds
as a result.

(In reply to comment #8)

Yes, you can see an awesome number of distinct
things go wrong as you slide the window open or
closed in steps of fractions of a character width,
and even pixel by pixel.

This is perfectly expected, as you are entirely
changing the text rendering engine's detailed
internal operation with each new window width.

    [I spent time in two different careers writing
        [at 1/1024 subpixel accuracy, for
        anti-aliasing, the second go around]
    text rendering software -- once for nautical
    charts, once for desktop presentation graphics
    software. It isn't at all easy to get right,
    especially for those polka-dotted test case
    fonts. ;-) ]

That "sliding the window width forth and back" is
thus a necessary test to see whether the problem is
fixed. Rendering the text correctly at one
particular pre-set window width is "moderately
easy", rendering it correctly at all window widths
is "not at all as easy".

xanthian.



(In reply to comment #10)
> Bug 332649 possibly has relation to this bug, although I think not DUP. 
> Test case of Bug 332649 is text overlap case after font switch to render
> special character(not included in font).
> 

Well, that covers nicely the second case of damage seen
in the attachment of my comment #5. Is it possible that
the other bug is experiencing the rest of the problems
seen with the example URL here? I've posted a note to
that bug inviting its developers to look at this bug.

xanthian.

CCing to Nakano-san.
Nakano san, is this bug a DUP of Bug 332649?
Unable to re-produce problem with Firefox trunk 2008/8/14 build, test URL by bug opener and test scenario of my comment #7 & comment #8.
Already WORKSFORME in my environment.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: