95280 - want to disable outline scaled fonts

Status: RESOLVED WONTFIX

(Core :: Internationalization, defect)

Description

[kill this account]

there is a request that outline scaled fonts be handled as if they were bitmap
scaled fonts.

Francisco: the original issue was that the Linux code was scaling
I suggested some prefs settings but that has other side effects.

In this bug can we identify what happens with default setting?

With default font.scale.blahblah settings are you getting outline 
scaling or bitmap scaling?

Using the default setting would you kindly produce a simple test case, and 
attach moz's output with NS_FONT_DEBUG=9, and a screen shot.

thanks

Comment 1

[Francisco León]

With defaults settings there is no bug, but the monospace font looks ugly, we
have been in this road for too long already. I use the modified font.scale
option in order to override scaling so the monospace font looks like 0.9.1 again

The only "mid workaround" i see to know, is to put the font.scale settings in
size 20 so the /home/something/ text looks in size 20 and the webpages that
break also do not show up so big.

Still, we should not have let the ugly monospace font bug stay, the font code
should have been reverted to 0.9.1 in order to properly FIX this instead of
using lame workarounds that are creating new bugs like this.

So, to recap, there is no bug 95280 with default settings. But bug 87055 should
be reopened now that the new bug has been marked invalid

Comment 2

[kill this account]

This bug is: "With defaults settings ... the monospace font looks ugly"

This is a separate bug from bug 87055 and that bug should not be reopened.

Using the default setting would you kindly produce a simple test case, and 
attach moz's output with NS_FONT_DEBUG=9, and a screen shot. 

Comment 3

[Francisco León]

Attachment: Screenshot with default settings

Comment 4

[Francisco León]

Attachment: Debug font output with defaults

Comment 5

[Francisco León]

Something happened with the debug output. Coming right up

Comment 6

[Francisco León]

I cannot get the debug output saved
I do, as always, export NS_FONT_DEBUG=9
and run /usr/local/mozilla/mozilla > font.txt and that's the only thing that
gets saved (the stuff in the attachment i made)

Comment 7

[Francisco León]

Attachment: Finally, debug output with normal settings

Comment 8

[kill this account]

in attachment 45858 [details] I see several things:

1) the text "This bug is: ..." has some of its lower pixels cut off.

2) the text "Additional Comments From" has the "m" glyph in "from" pixel shifted
   the text "bug 87055" has the "55" glyphs pixel shifted.
   the "kindly produce a simple test c" glyphs are pixel shifted.
   the "NS_FONT_DEBUG=9" has the "BUG=9" glyphs pixel shifted.

3) the lower case 'a' has one extra pixel set
   the lower case 'b' has two extra pixels set
   the upper case 'U' has one extra pixel set
   the lower case 'w' as 2 or 3 extra pixels set and is probably missing one
   the upper case 'B' has one extra pixel set

I believe items 1 and 2 are layout / reflow problems not font problems.

Does #3 the describe the problem you are reporting?

Comment 9

[Francisco León]

Attachment: Expected monospace font

Comment 10

[Francisco León]

Yeah, in attachment 45858 [details] i was able to make mozilla cut some pixels in the
first part (does it everytime) and i guess #3 is what you are saying. I am not
that technical and have not used xmag in order to compare the letters to see the
differences, i just see them ugly :)

Also, the hyphens is the most known letter that looks ugly. Remember my
attachments in the "fonts look terrible" bug

I have put a new attachment here of the same piece of text so you can compare them
That's the way 0.9.1 used to look

Comment 11

[kill this account]

> in attachment 45858 [details] i was able to make mozilla cut some pixels in the
> first part (does it everytime) 

That looks like a dup of bug 87738. 

Does the pixel shift occur when the page is covered/uncovered?

Does the pixel shift occur when the page is scrolled?

Do you want to open a new bug for this?

> [I] have not used xmag in order to compare the letters to see the
> differences, i just see them ugly :)

To fix a bug an engineer needs specific input. Would you kindly 
look carefully (perhaps with xmag) and determine if this indeed is the 
issue we are addressing in this bug?

> the hyphens is the most known letter that looks ugly. 

Are you talking about the hypens in "2001-08-14"?

Comment 12

[Francisco León]

I havent been able to determine what makes the pixels shift

About the xmag issue, i put here both good and bad attachments. If you look at
them closely, with or without xmag, almost all letters are badly rendered:
W, y, o, p, e, ', b, t, and some others look different, and mostly all letter
look thinner and somewhat longer

Yes, xmag reveals the issue you described with the letters but in general all
letters look somewhat different

Are you asking me to file a new bug or just my opinion if we should open a new
bug for the pixel shift? I think fixing bug 87738 will fix that one. If not, i
will be the first one to complain and file a new bug :)

Also, the "good" monospace font wont shift up or down, and wont display bug
87738's behaviour

The hyphens, look at http://bugzilla.mozilla.org/showattachment.cgi?attach_id=40087
See, they are small and thin, they should look bigger and thicker

Comment 13

[kill this account]

> and mostly all letter look thinner and somewhat longer

They *should* look thinner / longer.  The glyphs in attachment
45870 [details] are *not* the correct size, they are too small.

When the requested size was not available the old 0.9.1 code 
generally choose an incorrect size rather than scale because 
that code could not distinguish between bitmap scaled fonts 
(very ugly looking) and outline scaled fonts (generally 
considered to be okay looking).

Hand tuned (bitmap non-scaled) fonts almost always look the 
best.

> ... xmag reveals the issue you described with the letters 
> but in general all letters look somewhat different
>
> Are you asking me to file a new bug or just my opinion if we 
> should open a new bug for the pixel shift?

I want to make sure exactly which problem we are trying to 
solve.

I had been assumming the pixel shift was a client side issue 
but I wonder if it might be a server side issue. Perhaps
the font server on your system has a bug.

If the problem we are trying to fix is client side pixel
shift then we would take one course of action: 

  make a reproducable case, figure out what is causing 
  this, assign it to the correct person, and get it 
  fixed

If the problem we are trying to fix is server side pixel
shift then we would take a different course of action:

  try and detect if the user's font server is one of the
  font servers that has this problem and if do not use 
  outline scaled fonts on *that* system
  
If the problem we are trying to fix is that users would
prefer "hand-tuned but wrong sized" fonts then we would
take a different course of action:

  allow the user to disable outline scale fonts (or mark
  them the same as bitmap scaled fonts) 

> The hyphens, look at attachment 40087 [details], ... they are small
> and thin, they should look bigger and thicker

It is a dangerous business for an *application* to try to
judge and/or fix the exact style of a font's glyphs.

What exactly would be the logic to *programmatically* determine
a font is good/bad looking?

Comment 14

[Francisco León]

Well, what determines to my logical opinion what makes a font good or bad is:
-Alignment: all letters should be on the same line, with no pixel shifts. bug
87738 should fix this
-Consistency: all letters should be the same size
, and never should jag
-Accuracy: letters should be easy to read, with the exact number of pixels 

I think the "nice" attachment i sent you should be our goal. Well, we have
differences of opinion. I like the way it looks. Pixels never shift, letters are
all the same size, aligned, consistent and accurate. However, non monospace
fonts (like the one that says reporter: bstell sometimes jags, but very little.
It does not look clean enough like the monospace font

About a font server bug. I dont know about this. I am using xfree 4.1.0 on
mandrake 8

I think what you said in the last part, using hand tuned fonts that may be
wrongly sized is what you described 0.9.1 did, and that way the fonts look good.

I think people cares more of how the fonts look rather than having an exact size
of them .

I also think that there is *no* possible testcase on this, as the only testcase
possible would be in pixel shifting and jagging on the fonts, and again, that
does not belong in this bug but in the other one mentioned

Comment 15

[kill this account]

We are all agree that pixel shift in glyphs is a bug.

A correct fix will depend on knowing if this is client side or server side.

If the problem is that one user would prefer "best look" over "correct size"
then perhaps a workaround allowing that one user to disable outline scaling
might be the reasonable solution.

However, if the problem is pixel shift and that pixel shift is related to 
server side outline scaling I want to figure out what causes this before I 
add a workaround to turn of outline scaling. I rarely find that sweeping a 
problem under the carpet is a good idea.

Comment 16

[kill this account]

--> ftang

Comment 17

[Frank Tang]

bulk move NEW FUTURE bug to ASSIGN

Comment 18

[Frank Tang]

what a hack. I have not touch mozilla code for 2 years. I didn't read these bugs
for 2 years. And they are still there. Just close them as won't fix to clean up.

Comment 19

[Travis Chase]

Mass Re-open of Frank Tangs Won't fix debacle. Spam is his responsibility not my own

Comment 20

[Travis Chase]

Mass Re-assinging Frank Tangs old bugs that he closed won't fix and had to be
re-open. Spam is his fault not my own