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

Submitter:  Tom Wadzinski <tomw>
Submitted:  Wed 15 Apr 2009 03:11:12 PM UTC
   
 
Category:  overall font problem Severity:  3 - Normal
Item Group:  bulk text appearance poor Status:  Duplicate
Privacy:  Public Assigned to:  Stevan_White
Open/Closed:  Closed Release:  * 2009-01-04
* Mandatory Fields

Add a New Comment Rich Markup
   

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 #18066)

Steve White <Stevan_White>
Group administrator
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>
Group administrator
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>
Group administrator
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>
Group administrator
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 Files:
   
   
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
  • -email is unavailable- added by Stevan_White (Posted a comment)
  • -email is unavailable- added by tomw (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-05-03 Stevan_White Open/ClosedOpen Closed
    2009-05-01 Stevan_White Attached File- Added freesans.png, #18065
        Attached File- Added Overshoot.html, #18066
    2009-04-27 Stevan_White StatusNone Duplicate
        Assigned toNone Stevan_White
    2009-04-15 tomw Attached File- Added Picture 49.png, #17922

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code