198890 - visible bug in rendering negative spacing in CSS

Status: RESOLVED FIXED

(Core Graveyard :: GFX: BeOS, defect)

Description

[Sergei Dolgov]

Style constructions like that

.morelink {
	font-family: Verdana, Helvetica, sans-serif;
	font-size: 8pt;
	color: #000066;
	letter-spacing: -1px;
}
cause ugly rendering in BeOS - overlapping words, wrong break-points (no
wrapping where it was expected to be)
second example may be probably 
http://www.submarino.com.br

Partially it is BeOS GFX implemetation bug - currently DrawString(string,
spacing !=0 ) uses word-by-word rendering for aligned drawing. For speed
reasons. So only first letter of each word is placed according to spacing
information.
But in this case also MacOS port should suffer from this bug, cause it also uses
word-by-word drawing.

Also yet understandable for me is reason of non-wrapping. But that's may be due
inimplemented GetTextDimensions

Comment 1

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

->Gfx:BeOS

Comment 2

[Sergei Dolgov]

will submit patch soon - changing assignment

Comment 3

[Sergei Dolgov]

this also "duplicates" some current bugs about improper rendering of aligned
BiDi text (arabic and hebrew)

Comment 4

[Sergei Dolgov]

Attachment: Path. Rollaback to first patch proposed for bug 125132

Paul, try to test/review it as soon as possible, in reality it is old solution
approved by you and Daniel, and it is blocking further patches on text
rendering here.

Comment 5

[Sergei Dolgov]

Comment on attachment 119436 [details] [diff] [review]
Path. Rollaback to first patch proposed for bug 125132 

review request

Comment 6

[Paul]

Attachment: screenshot of renderign with above patch

When displaying the URL on this bug with attachment 119436 [details] [diff] [review], the word "online"
is hard to read on that page, because there is no spacing in between the 'n'
the 'l' and the 'i'.  I tried to render the same page under a windows build of
mozilla, to see how it handled it, and, in fact, a gap was placed between those
characters.  Attached is a screenshot of what I mean.

Is there a way to easily determine how far from the previous char drawn are we
when we go to draw a char, so we can try to ensure space (at least one pixel)
exists between chars in a word?

Comment 7

[Paul]

Comment on attachment 119436 [details] [diff] [review]
Path. Rollaback to first patch proposed for bug 125132 

r=arougthopher

Comment 8

[Paul]

Comment on attachment 119436 [details] [diff] [review]
Path. Rollaback to first patch proposed for bug 125132 

teach me to look a little closer.  just as I was about to check this in, I
noticed the patch was producing a compiler warning.  Updated patch to follow

Comment 9

[Paul]

Attachment: updated patch, minus the warning

Comment 10

[Paul]

Comment on attachment 120663 [details] [diff] [review]
updated patch, minus the warning

r=arougthopher

Comment 11

[Paul]

This has been checked in