bugThe FreeType Project - Bugs: bug #29077, TrueType interpreter manufactures...

 
 

bug #29077: TrueType interpreter manufactures vertical advance width

Submitted by:  Kenneth Sharp <kens>
Submitted on:  Fri 05 Mar 2010 01:08:13 PM UTC  
 
Severity: 3 - NormalItem Group: None
Status: Wont FixPrivacy: Public
Assigned to: Werner LEMBERG <wl>Open/Closed: Closed
Planned Release: None

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

(Jump to the original submission Jump to the original submission)

Mon 08 Mar 2010 05:14:12 PM UTC, comment #6:

Thanks for the information.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Mon 08 Mar 2010 04:36:31 PM UTC, comment #5:

The Adobe Tech Note 5012, The Type 42 Font Format Specification, page 18 "5.6 Vertical Writing Mode" covers this. Put simply the vmtx can only be used by a CIDFont with type 42 outlines, not a simple Type 42 font. In this case the CIDFont will have a WMode of 1, so we know that vertical metrics are to be used, not horizontal ones.

I still think it would be useful to be able to instruct FreeType not to synthesise metrics information which is not present in the font, however I can and have modified our code to burrow into the font data, determine the type, and if it is a simple type 42 to use the metrics override callback to set the advance to 0.

So please go ahead and close this issue, the problem is resolved.

Kenneth Sharp <kens>
Project Member
Fri 05 Mar 2010 04:11:24 PM UTC, comment #4:

Not yet. I do know that the spec says type 42 fonts 'should' have an identity matrix, but I am not aware of much more than that. I'll see if I can turn up anything in the T42 spec.

After I've debugged the type 42 font with the funny behaviour when ignoring the vertical advance value.

Kenneth Sharp <kens>
Project Member
Fri 05 Mar 2010 04:05:23 PM UTC, comment #3:

In the other bug report we've had a long discussion why GhostScript should ignore FreeType's `vertical' writing direction completely. Even for a Type 42 font I believe that you should never access the vertical metrics data.

I must admit that I'm not aware of any description how a Type 42 behaves if used for the vertical writing direction. Do you have any pointer?

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Fri 05 Mar 2010 03:46:14 PM UTC, comment #2:

Well, firstly because the higher level code need not know what format the font is in, it just sends the font to FreeType for processing, and handles the returned data.

We assume that returned data is always correct and apply any horizontal or vertical advances. We'd need to add extra code to discard the vertical advance from TrueType fonts only, which is possible, but....

I did initially try fixing the vertical advance at 0 for TrueType glyphs (to avoid any change to FreeType) and a test file exhibited severe problems with positioning. This particular test file uses a type 42 font which 'appears' to use both vertical and horizontal metrics to position the glyphs; some glyphs move the current point vertically, others horizontally, but I will go back to that file and confirm if this is the case.

Kenneth Sharp <kens>
Project Member
Fri 05 Mar 2010 03:35:41 PM UTC, comment #1:

I don't see a need for a new flag. For the PS interpreter, always process a font in the horizontal writing direction.

Is there a case where you need to load a glyph in vertical mode?

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Fri 05 Mar 2010 01:08:13 PM UTC, original submission:

In ttgload.c, compute_glyph_metrics, line 2647:

/* Now take care of vertical metrics. In the case where there is */
/* no vertical information within the font (relatively common), */
/* create some metrics manually */

I can see why this is useful in a pure TrueType environment, as the writing direction is known. If the font has no vertical metrics (which are optional) but is used in a vertical writing mode, some approximate metrics are important.

However, for a PostScript interpreter, there is no concept of a writing direction. Glyphs are simply drawn and then the current point advanced by the horizontal and vertical advances. See bug #28678 for (extensive) discussion of this point related to type 1 fonts.

Now, when processing a type 42 font we supply the sfnts data to FreeType as a TrueType font. The data is correctly processed and the glyph rendered. However, if there is no vhea/vmtx data, then the code in ttgload.c creates some useful metrics and supplies these back.

The PostScript interpreter, not knowing which way the text is advancing, simply applies both metrics, with the result that the glyphs advance 'diagonally' instead of horizontally.

I appreciate that the synthesised information is highly useful to 'real' TrueType users, but its devastating in the PostScript environment.

Would it be possible to switch off this metric synthesis, perhaps by using a new FT_LOAD flag ? (so that existing users need not change their code I would suggest FT_LOAD_NO_SYNTHETIC_METRICS)

Attached patches to achieve this effect. (please be aware that the line numbers in ttgload.c.diff may not match the GIT repository)

Kenneth Sharp <kens>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #19851:  freetype.h.diff added by kens (3KiB - application/octet-stream)
file #19852:  ttgload.c.diff added by kens (408B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    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 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 08 Mar 2010 05:14:12 PM UTCwlStatusNeed Info=>Wont Fix
      Open/ClosedOpen=>Closed
    Fri 05 Mar 2010 03:35:41 PM UTCwlStatusNone=>Need Info
      Assigned toNone=>wl
    Fri 05 Mar 2010 01:08:13 PM UTCkensAttached File-=>Added freetype.h.diff, #19851
      Attached File-=>Added ttgload.c.diff, #19852
      Carbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup1