bugFree UCS Outline Fonts - Bugs: bug #26187, FreeSans TTF 'e', and others drop...

 
 

bug #26187: FreeSans TTF 'e', and others drop down as font size increases

Submitted by:  Tom Wadzinski <tomw>
Submitted on:  Wed 15 Apr 2009 03:11:12 PM UTC  
 
Category: overall font problemSeverity: 3 - Normal
Item Group: bulk text appearance poorStatus: Duplicate
Privacy: PublicAssigned to: Steve White <Stevan_White>
Open/Closed: ClosedRelease: 2009-01-04

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Fri 01 May 2009 09:18:28 AM UTC, comment #5:

Tom,

I did some experimentation, and looked at the standards.
A PDF file clarifying overshoot issues is available: "Adobe Type 1 Font Format", especially ch. 5 and sect. 3.2

I then reviewed the PS Private entries for all the faces in FreeFont, and made some adjustments: especially the BlueValues and Stem widths were off; now BlueFuzz is disabled.

However, I don't see that these PS Private values make any difference in rendering on my sytems. Still in Sans sizes from about 14pt to 20pt, the overshoot appears excessive (in Gnome/Pango, 96DPI, anti-aliasing RGB, full). In FreeSerifBold, the effect is worse and is noticeable in a larger range of sizes.
It may be that these settings are considered outdated.

The "jump" in the overshoot that is apparent in your screen shot may be due to a setting. On my Ubuntu system, System Settings -> General -> Appearance -> Fonts has a button Use anti-aliasing -> Configure... ; the "Exclude Range" setting has an effect.

While the Type 1 BlueValues are clearly related to this issue, I doubt how effective they would be here, even if they were properly implemented. They are explicitly designed to avoid rendering overshoots in small font sizes, where the excess caused by turning on a single pixel would be distracting. Here, we have an obvious overshoot at much larger font sizes. And we are looking at LCD screens with anti-aliasing capabilities.

I'm not sure of the use of BlueScale values. Maybe that can have some effect.

It seems that the Sans face (again, originally from the Nimbus fonts) simply has a very large overshoot. It is twice that of the DejaVu Sans face, for example. It looks OK in very large sizes, but poor in medium ones.

In GTK systems, you can experiment with this command:
pango-view --font="freesans" --waterfall -q -o out.png in.txt
(See example output attached.
Also, I attached an HTML file that can be used for experimenting (use CSS to adjust styles.)

(file #18065, file #18066)

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Tue 28 Apr 2009 06:42:16 AM UTC, comment #4:

Tom,

Cool that you can have a look at it. This is supposed to be a community effort, after all!

As to what to do, I can't say exactly. You might just report what changes have what effects.

I don't know why the designers of Nimbus chose such large overshoots. Maybe they had a particular font size in mind. (Old metal types would vary the overshoot for proper effect in a specific font size, fancier font technologies could do this too, but TrueType is just too dumb.) But I don't know for sure what they did is wrong, or the cause of the problem.

That it looks better to you without the font renderer's hinting is a clue.

The font settings are all under the Font Information dialog.

As I said, the only font setting that looks obviously wrong is that Blues thing. Sure, try just deleting it and see if it makes any difference.

Besides that, the settings (that I know of) that affect hinting are the other Blues values (whose working is obscure to me), and the Grid Fitting. Note that the Grid Fitting panel is painfully buggy in this version of FontForge--it can be made to hold your desired values though.

The procedure to build TrueType is:
1) select all 2) autohint 3) change all Layers to quadratic 4) autoinstruct 5) Generate TrueType.

Also: when you're experimenting, it can be tricky to know which version of the font you're lookin at. On your Linux system, be sure to do a 'locate FreeSans' to make sure you're only seeing the locally installed copy.

Good luck!

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Mon 27 Apr 2009 10:27:43 PM UTC, comment #3:

Thanks much for having a look at this. Based on your response and the related bug, I tried turning off autohinting in freetype which created a more pleasing result for FreeSans, without the extra dropping that was occurring at certain font sizes.

I could experiment with what you mentioned if you give me a further pointer on what to do. I have fontforge and the SFD files. Are you suggesting maybe removing (if possible) the OtherBlues value?

Tom Wadzinski <tomw>
Mon 27 Apr 2009 10:16:26 PM UTC, comment #2:

I am looking into the fonts.

In Sans and SansBold, the overshoot of the letter e is the same, althought in Sans it is a greater proportion of the stem width.

Other effects could be caused by "PS Private" settings, or by Grid Fitting. I see nothing wrong with the latter, and I don't know much about the former.

But you know, there is an oddity in Sans that doesn't appear in SansBold. There is an "OtherBlues" table in "PS Private", reading
[-218 -218]
I don't know what that means. I think it's trash. (But auto-generated trash...probably caused by some unfortunate glyphs.)

Now, I think Blues values are used for TrueType Auto-Hinting. Maybe this throws it off.

Tom, do you have the technology to experiment with this?
All you need are the SFD files from the distribution and FontForge 20080429.

Cheers!

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Mon 27 Apr 2009 07:54:56 AM UTC, comment #1:

Tom,

I think this is similar to the "excessive overshoot" issue mentioned in report 22266
https://savannah.gnu.org/bugs/?22266

Now, overshoot, per se, is an accepted stylistic technique, that is meant to make round letters appear more in-line with flat ones.

It appears to me to be a combination of a (perhaps unfortunately) large overshoot in the glyphs in the original Nimbus fonts, and how various rendering systems choose to handle that (at various font sizes). But to my eyes too, sometimes the overshoot is excessive.

I don't know what to do about it at this time. Maybe the answer would be to replace the underlying Nimbus fonts... Or else maybe there is some technical issue I'm missing...

Any ideas are welcome!

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Wed 15 Apr 2009 03:11:12 PM UTC, original submission:

In 20090104 and earlier FreeSans tested on Linux and Mac (using SDL_TTF or Pango, which use freetype under the hood), I'm experiencing the following problem:

In the attached screenshot, notice the non-bold line of a's near the bottom. As the font size increases, the low point of the 'a' drops down, and later jumps back up. Then notice the non-bold Ma's. When the a shifts down the M doesn't, making the text look quirky. The same test case is shown with FreeSansBold where the problem does not exists

This does not happen with FreeSansBold, which leads me to think that this might indicate a problem with the font, rather than with Freetype or some other piece along the chain to the screen.

However, when I use FreeSans with another tool, like Mac Textedit, I don't experience the dropped letter problem. If I do Ma of different sizes, the M and the a stay in sync as the size increases, so it may not be the font's 'fault'.

Tom Wadzinski <tomw>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #18065:  freesans.png added by Stevan_White (82KiB - image/png)
file #18066:  Overshoot.html added by Stevan_White (910B - text/html)
file #17922:  Picture 49.png added by tomw (447KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by Stevan_White (Posted a comment)
  • -unavailable- added by tomw (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 03 May 2012 06:54:09 PM UTCStevan_WhiteOpen/ClosedOpen=>Closed
    Fri 01 May 2009 09:18:28 AM UTCStevan_WhiteAttached File-=>Added freesans.png, #18065
      Attached File-=>Added Overshoot.html, #18066
    Mon 27 Apr 2009 07:54:56 AM UTCStevan_WhiteStatusNone=>Duplicate
      Assigned toNone=>Stevan_White
    Wed 15 Apr 2009 03:11:12 PM UTCtomwAttached File-=>Added Picture 49.png, #17922

    Back to the top


    Powered by Savane 3.1-cleanup1