Bug 7603

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.

Created attachment 6314 [details]
Arial 40 point at 200% zoom in Acrobat

Here's a png image of the Arial font at 40 point.

Isn't the PDF backend using FreeType even on Windows?1

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

 

(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

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.

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.

This patch looks good, it does exactly the right thing.

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.

(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).

(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.

I committed the last patch and a couple of the clean ups I mentioned.  Closing
this bug, thanks for the patch.

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

Created attachment 6473 [details] [review]
Possible fix

This patch seems to fix the problem with creating type3 fonts from Windows
fonts.

Created attachment 6474 [details] [review]
Possible fix

This patch seems to fix the problem with creating type3 fonts from Windows
fonts.

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.

(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.

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.

Thanks Adrian.  Yes, PS/PDF have the same bug with font_matrix rotations.  I'll
look into that in a few days.

(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

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.