bugThe FreeType Project - Bugs: bug #57519, t1_decoder_parse_metrics does not...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #57519: t1_decoder_parse_metrics does not handle op_div

Submitter:  Tor Andersson <ccxvii>
Submitted:  Thu 02 Jan 2020 03:13:40 PM UTC
   
 
Severity:  3 - Normal Item Group:  Incorrect behaviour
Status:  Fixed Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  2.10.2

Jump to the original submission

Mon 24 Feb 2020 10:40:48 AM UTC, comment #9: 

Works beautifully! Thank you very much!

Tor Andersson <ccxvii>
Fri 21 Feb 2020 08:01:56 PM UTC, comment #8: 

Now fixed in git.  Please test!

Werner LEMBERG <wl>
Group administrator
Fri 21 Feb 2020 04:24:51 PM UTC, comment #7: 

No progress yet, sorry.  Will hopefully fix it soon.

Werner LEMBERG <wl>
Group administrator
Fri 21 Feb 2020 03:19:59 PM UTC, comment #6: 

Any progress on this bug?

We've been getting quite a number of bug reports related to this from MuPDF users who are using FreeType from their distros. I have a workaround in MuPDF by building with T1_CONFIG_OPTION_OLD_ENGINE=1, but that fix is not available for distributions that always link programs against system libraries.

Tor Andersson <ccxvii>
Fri 03 Jan 2020 05:19:28 PM UTC, comment #5: 

Thanks for the test program.  I looked at the wrong function, which actually handles `op_div`.  Will check whether there is an easy fix.

Werner LEMBERG <wl>
Group administrator
Fri 03 Jan 2020 02:54:31 PM UTC, comment #4: 

I read the source. There is no handling of the 'div' operator in t1_decoder_parse_metrics. It'n also possible to verify this by the debug tracing printing saying "no width, found op 12 instead" when it encounters the 'div' operator in that function.

The code for t1_decoder_parse_metrics is a stripped down copy of the code for t1_decoder_parse_charstrings which leaves out most operators (as expected) but it has unfortunately also stripped out handling the 'div' operator.

Before commit dff40d03dff05734b8bf026716b780688f89e830 freetype returned the correct metrics; after that commit it no longer does.

Run the example program I attached to see metrics. The expected output is:

glyph 0: advance = 280
glyph 1: advance = 750
glyph 2: advance = 500
glyph 3: advance = 556
glyph 4: advance = 722
glyph 5: advance = 444
glyph 6: advance = 278
glyph 7: advance = 764
glyph 8: advance = 556
glyph 9: advance = 681
glyph 10: advance = 444
glyph 11: advance = 653
glyph 12: advance = 306
glyph 13: advance = 500
glyph 14: advance = 556
glyph 15: advance = 333
glyph 16: advance = 361
glyph 17: advance = 625
glyph 18: advance = 278
glyph 19: advance = 917
glyph 20: advance = 833
glyph 21: advance = 750
glyph 22: advance = 556
glyph 23: advance = 500
glyph 24: advance = 500
glyph 25: advance = 681
glyph 26: advance = 556
glyph 27: advance = 278
glyph 28: advance = 778
glyph 29: advance = 528
glyph 30: advance = 392
glyph 31: advance = 556
glyph 32: advance = 394
glyph 33: advance = 389
glyph 34: advance = 500
glyph 35: advance = 750
glyph 36: advance = 556
glyph 37: advance = 750
glyph 38: advance = 528
glyph 39: advance = 722
glyph 40: advance = 528
glyph 41: advance = 278
glyph 42: advance = 306

The output with the most current git:

glyph 0: advance = 280
glyph 1: advance = 750
glyph 2: advance = 500
glyph 3: advance = 0
glyph 4: advance = 0
glyph 5: advance = 0
glyph 6: advance = 0
glyph 7: advance = 0
glyph 8: advance = 0
glyph 9: advance = 0
glyph 10: advance = 0
glyph 11: advance = 0
glyph 12: advance = 0
glyph 13: advance = 500
glyph 14: advance = 0
glyph 15: advance = 0
glyph 16: advance = 0
glyph 17: advance = 625
glyph 18: advance = 0
glyph 19: advance = 0
glyph 20: advance = 0
glyph 21: advance = 750
glyph 22: advance = 0
glyph 23: advance = 500
glyph 24: advance = 500
glyph 25: advance = 0
glyph 26: advance = 0
glyph 27: advance = 0
glyph 28: advance = 0
glyph 29: advance = 0
glyph 30: advance = 0
glyph 31: advance = 0
glyph 32: advance = 0
glyph 33: advance = 0
glyph 34: advance = 500
glyph 35: advance = 750
glyph 36: advance = 0
glyph 37: advance = 750
glyph 38: advance = 0
glyph 39: advance = 0
glyph 40: advance = 0
glyph 41: advance = 0
glyph 42: advance = 0


(file #48161)

Tor Andersson <ccxvii>
Fri 03 Jan 2020 02:24:32 PM UTC, comment #3: 

Please kindly provide more details. When you say "wrong values", elaborate with some specific expected and obtained numbers.

I think the parsing stack is always in the 16.16 format and handling 'div' is implemented accordingly.

Alexei Podtelezhnikov <podtelez>
Group Member
Thu 02 Jan 2020 09:21:23 PM UTC, comment #2: 

FT_Get_Advance returns the wrong values.

Built with FT_DEBUG_LEVEL_TRACE this message appears in the trace:

t1_decoder_parse_metrics: no width, found op 12 instead

Operator 12 is 'div'.

Another related message also appears:

t1_decoder_parse_metrics: large integer found for width

Tor Andersson <ccxvii>
Thu 02 Jan 2020 06:27:21 PM UTC, comment #1: 

Using current git, the PFA file you've attached to this bug report gets loaded by FreeType without any error or problem, as can be seen in the attached screenshot.  Even older versions load it just fine.

Why do you have the impression that `t1_decoder_parse_metrics` is not capable of handling the `div` operator?


Werner LEMBERG <wl>
Group administrator
Thu 02 Jan 2020 03:13:40 PM UTC, original submission:  

The Type1 fonts created by pdflatex include charstrings that use
the div operator to set the character metrics. This is not handled
by the limited interpretation in t1_decoder_parse_metrics.

For example files, see these bug reports for mupdf:

https://bugs.ghostscript.com/show_bug.cgi?id=701602
https://bugs.ghostscript.com/show_bug.cgi?id=701977
https://bugs.ghostscript.com/show_bug.cgi?id=701979

An example charstring from one of these files that is not handled properly:

/one {
        86 12647 23 div
        hsbw
-snip-

Tor Andersson <ccxvii>

 

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

Attached Files
file #48161:  ftmet.c added by ccxvii (829B - text/x-csrc)
file #48159:  adobe-engine.png added by wl (33KiB - image/png)
file #48157:  VFHLSD+LMRoman10-Regular-0013.pfa added by ccxvii (29KiB - application/x-font-type1)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by podtelez (Posted a comment)
  • -email is unavailable- added by wl (Updated the item)
  • -email is unavailable- added by ccxvii (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.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-02-21 wl StatusConfirmed Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 2.10.2
    2020-01-03 wl StatusNeed Info Confirmed
    2020-01-03 ccxvii Attached File- Added ftmet.c, #48161
    2020-01-02 wl Attached File- Added adobe-engine.png, #48159
        StatusNone Need Info
        Assigned toNone wl
    2020-01-02 ccxvii Attached File- Added VFHLSD+LMRoman10-Regular-0013.pfa, #48157

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code