Bug 7603 - Cairo creates incorrect type 3 fonts when using win32 font
Summary: Cairo creates incorrect type 3 fonts when using win32 font
Status: RESOLVED FIXED
Alias: None
Product: cairo
Classification: Unclassified
Component: pdf backend (show other bugs)
Version: 1.2.1
Hardware: x86 (IA32) Windows (All)
: high normal
Assignee: Kristian Høgsberg
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-23 05:51 UTC by Adrian Johnson
Modified: 2006-08-21 09:58 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Arial 10 point at 800% zoom in Acrobat (3.21 KB, image/png)
2006-07-23 05:55 UTC, Adrian Johnson
Details
Arial 40 point at 200% zoom in Acrobat (3.82 KB, image/png)
2006-07-23 05:57 UTC, Adrian Johnson
Details
Add support for win32 truetype fonts without freetype (32.04 KB, patch)
2006-08-01 07:18 UTC, Adrian Johnson
Details | Splinter Review
Add support for win32 truetype fonts without freetype (45.00 KB, patch)
2006-08-02 04:01 UTC, Adrian Johnson
Details | Splinter Review
Possible fix (5.04 KB, patch)
2006-08-06 07:56 UTC, Adrian Johnson
Details | Splinter Review
Possible fix (5.04 KB, patch)
2006-08-06 07:57 UTC, Adrian Johnson
Details | Splinter Review
Fix updated to include matrix transform (6.87 KB, patch)
2006-08-21 06:59 UTC, Adrian Johnson
Details | Splinter Review

Description Adrian Johnson 2006-07-23 05:51:56 UTC
When creating a PDF file using a Win32 font the font
outline is incorrect for some chacters at small font sizes.
I am using cairo compiled under Cygwin.

The generated postscript has exactly the same problem.

I have found that the problem is in the data returned by
the GetGlyphOutlineW() in _cairo_win32_scaled_font_init_glyph_path().

eg for the letter 'h' at 10 point, GetGlyphOutlineW() returns the
outline made up of the following TTPOLYCURVEs:

TT_PRIM_LINE    3
TT_PRIM_QSPLINE 4
TT_PRIM_LINE    10
TT_PRIM_QSPLINE 4
TT_PRIM_LINE    1

where the number is the number of points in each TTPOLYCURVE.

At 40 points, GetGlyphOutlineW() returns

TT_PRIM_LINE    3
TT_PRIM_QSPLINE 2
TT_PRIM_QSPLINE 4
TT_PRIM_LINE    3
TT_PRIM_QSPLINE 3
TT_PRIM_QSPLINE 4
TT_PRIM_LINE    1

The documentation for GetGlyphOutline() states that outline returned is grid
fitted and if an application requires an unmodified outline it can request an
outline for a font whose size is equal to the font's em unit.

This seems to suggest that the solution to this bug would be to obtain the
unmodified outline data and scale it to the required size.
Comment 1 Adrian Johnson 2006-07-23 05:55:09 UTC
Created attachment 6313 [details]
Arial 10 point at 800% zoom in Acrobat

Here's a png image of the problem occuring with a 10 point Arial font.
Comment 2 Adrian Johnson 2006-07-23 05:57:04 UTC
Created attachment 6314 [details]
Arial 40 point at 200% zoom in Acrobat

Here's a png image of the Arial font at 40 point.
Comment 3 Behdad Esfahbod 2006-07-23 21:34:27 UTC
Isn't the PDF backend using FreeType even on Windows?1
Comment 4 Owen Taylor 2006-07-24 09:04:14 UTC
- I believe that cworth said that he was embedding with Type3 fonts always now;
  and that the "dependency" on FreeType for the PDF/PS backends on windows is
  spurious.

- However, it would be even better to be using the Type 42 embedding code that
  Kristian wrote. It's not a lot of work to get it up and running with native
  Win32 fonts, I think. The main issue is figuring out how not to re-embed the
  font at every different size. (I'm not sure that this has been dealt with 
  for the Type3 embedding either!)

- In terms of the hinting issue, there is some already code in the Win32 backend
  to handle working with the unhinted form of the font ... see the usage of
  _cairo_win32_scaled_font_select_unscaled_font(). The work to solve this
  particular problem is to hook that up to the font options that are passed
  in to the backend.

 
Comment 5 Carl Worth 2006-07-24 13:44:07 UTC
(In reply to comment #3)
> Isn't the PDF backend using FreeType even on Windows?1

It shouldn't use freetype for type 3 font embedding.

But, yes, the truetype embedding does use freetype, and that code would be
preferred once it is all working.

-Carl
Comment 6 Adrian Johnson 2006-08-01 07:18:42 UTC
Created attachment 6415 [details] [review]
Add support for win32 truetype fonts without freetype

This patch fixes the problem by using truetype fonts instead of type3 fonts
in PDF and PS output. It also has the benefit of removing the freetype
dependency on from the PDF and PS backends.
Comment 7 Behdad Esfahbod 2006-08-01 08:18:41 UTC
Thanks Adrian!  Can you add a comment to bug 7538 about your patch?  I don't
want to dup at this point as the two bugs describe two different problems.
Comment 8 Kristian Høgsberg 2006-08-01 14:24:30 UTC
This patch looks good, it does exactly the right thing.
Comment 9 Adrian Johnson 2006-08-02 04:01:08 UTC
Created attachment 6430 [details] [review]
Add support for win32 truetype fonts without freetype

I have updated the patch to:
- fix a bug
- Rename the *_pdf_ft_* functions in cairo-font-subset.c to *_truetype_*.
  This is now consistent with the function names in cairo-type1-subset.c .
- add a null entry for load_truetype_table() to cairo-atsui-font.c.
  The function ATSFontGetTable() looks like the atsui equivalent of
  FT_Load_Sfnt_Table() so it should be possible to implement
  load_truetype_table() in cairo-atsui-font.c.

The only remaining problem I am aware of is vertical font support.
I have commented out the code that caused a fallback to type 3 for vertical
fonts as it depended on a cairo-ft-font.c function. I have not found a
freetype independent method of determining if a font is vertical.

A better solution would be to provide support for vertical truetype fonts.
I have been testing a patch that that embeds the vhea/vmtx tables. It works
for PS (after editing the PS file to set WMode to 1). However I ran into
a problem with the PDF backend as WMode=1 only works for Type 0 composite
fonts in PDF.
Comment 10 Kristian Høgsberg 2006-08-02 07:28:50 UTC
(In reply to comment #9)
> Created an attachment (id=6430) [edit]
> Add support for win32 truetype fonts without freetype
> 
> I have updated the patch to:
> - fix a bug
> - Rename the *_pdf_ft_* functions in cairo-font-subset.c to *_truetype_*.
>   This is now consistent with the function names in cairo-type1-subset.c .

This makes sense, but it's probably better to do that in a separate patch.  Also, the file should be 
renamed to cairo-truetype-subset.c and we should remove cairo-font-subset-private.h.  Plus the 'base' 
struct embedded in cairo_pdf_ft_font_t is another left-over that should just be removed (likewise for 
the type1 code).
Comment 11 Behdad Esfahbod 2006-08-02 09:26:42 UTC
(In reply to comment #9)
> The only remaining problem I am aware of is vertical font support.
> I have commented out the code that caused a fallback to type 3 for vertical
> fonts as it depended on a cairo-ft-font.c function. I have not found a
> freetype independent method of determining if a font is vertical.

True.  We probably want to add the vertical option in cairo_font_options_t at
some point.  In the mean time, can't you make the freetype implementation of
get_table fail if the font is set to vertical?
 
> A better solution would be to provide support for vertical truetype fonts.

Indeed.  But I'm not sure what exactly happens if the font doesn't have vertical
metrics.  FreeType currently seems to synthesize vertical metrics such that for
example the ft-text-vertical-layout test works for any font.  That doesn't work
with the subsetting currently, and I think adding subsetting for vertical tables
may not help as they don't exist.  I may be quite wrong though, and I hope I am :).

> I have been testing a patch that that embeds the vhea/vmtx tables. It works
> for PS (after editing the PS file to set WMode to 1). However I ran into
> a problem with the PDF backend as WMode=1 only works for Type 0 composite
> fonts in PDF.
Comment 12 Kristian Høgsberg 2006-08-02 16:34:50 UTC
I committed the last patch and a couple of the clean ups I mentioned.  Closing
this bug, thanks for the patch.
Comment 13 Carl Worth 2006-08-02 16:38:25 UTC
I'd like to leave this bug open. If type3 fonts ever get used for some reason,
then the original bug still exists.

(Maybe that's pretty much moot because the buggy behavior depends on hints being
present, which will only happen with truetype (is that true?), and that will
always trigger truetype not type3 font subsetting.)

-Carl
Comment 14 Adrian Johnson 2006-08-06 07:56:18 UTC
Created attachment 6473 [details] [review]
Possible fix

This patch seems to fix the problem with creating type3 fonts from Windows
fonts.
Comment 15 Adrian Johnson 2006-08-06 07:57:19 UTC
Created attachment 6474 [details] [review]
Possible fix

This patch seems to fix the problem with creating type3 fonts from Windows
fonts.
Comment 16 Adrian Johnson 2006-08-20 16:19:34 UTC
Any comments on the patch "Possible Fix"? 

Now that cairo supports displaying Type 1 fonts on windows, it would be good to
get this bug closed as PDFs with Type 1 fonts created on windows require the
Type 3 fallback.
Comment 17 Behdad Esfahbod 2006-08-20 22:55:09 UTC
(In reply to comment #16)
> Any comments on the patch "Possible Fix"? 
> 
> Now that cairo supports displaying Type 1 fonts on windows, it would be good to
> get this bug closed as PDFs with Type 1 fonts created on windows require the
> Type 3 fallback.

Kristian took a look at this patch for 1.2.4, but he was not quite satisfied
with it.  He was supposed to add a comment here.  I do instead.  Basically, the
x_scale, y_scale approach doesn't seem to scale to non-scale scale matrices!!! 
What he suggests instead is using cairo_matrix_transform_point/distance.
Comment 18 Adrian Johnson 2006-08-21 06:59:25 UTC
Created attachment 6631 [details] [review]
Fix updated to include matrix transform

I have updated to patch to perform the matrix transform of the glyph outlines.

While this fixes the matrix tranform problem in the first patch it still does
not produce correct results in the PS/PDF output due to PS/PDF backend applying
the transform as well. As Type 3 fonts generated from the freetype backend also
produce exactly the same PS/PDF output I think that is a separate issue to this
bug.
Comment 19 Behdad Esfahbod 2006-08-21 08:58:57 UTC
Thanks Adrian.  Yes, PS/PDF have the same bug with font_matrix rotations.  I'll
look into that in a few days.
Comment 20 Kristian Høgsberg 2006-08-21 09:35:15 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > Any comments on the patch "Possible Fix"? 
> > 
> > Now that cairo supports displaying Type 1 fonts on windows, it would be good to
> > get this bug closed as PDFs with Type 1 fonts created on windows require the
> > Type 3 fallback.
> 
> Kristian took a look at this patch for 1.2.4, but he was not quite satisfied
> with it.  He was supposed to add a comment here.  I do instead.  

Thanks, Behdad
Comment 21 Kristian Høgsberg 2006-08-21 09:58:01 UTC
Patch committed, thanks.  As for the issue discussed in commets 18 and 19,
please consider that the right fix would be to only output one unit size font
for each cairo_font_face_t used in a document, and output the font matrix where
the font is used.  Closing bug.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.