Printing is broken on 10.9

[blueboxd]

On 10.9, characters on print preview are invisible, and the print result is filled with completely broken glyphs.

Seems code path with SkFontMgr_Mac::onMakeFromStreamArgs cannot create proper glyphs and renderer for printing follows that path.

[Wowfunhappy]

Possible clue? I noticed that if you open a PDF in Chromium's PDF viewer, and try to print, the text renders fine. But I don't know whether those actually go through Skia...

[blueboxd]

Thanks, that's very interesting.
I'll trace path for PDF renderer.

[Wowfunhappy]

When #2 was fixed by undoing this change in Skia, was this change in Chromium ever looked at? I have no idea what it does, but the commit message implies it was related somehow.

[blueboxd]

That commit was not reverted. But maybe there's crashing on 10.9 if code path follows that method...?
I'll trace that path too.

[Wowfunhappy]

Could setting kSettingRasterizePdf to True function as a workaround?

[blueboxd]

Thanks! I'll check it.

[macOS-Mavericks]

Trying to print on a 10.7.5 clean install causes Chromium to get stuck on the print dialogue, while it's trying to generate a preview, and then the app crashes.

[Wowfunhappy]

@macOS-Mavericks Can you post a crash log?

[macOS-Mavericks]

Chromium_2021-09-25-173302.txt
From Lion 10.7.5

[Wowfunhappy]

Symbol not found: _cupsEnumDests

You should probably open a new issue, looks totally different from the text rendering crash on Mavericks.

(I'd be tempted to try just replacing it with a stub similar to this.)

Edit: Followup for posterity, this was caused by not having Lion security update 2014-004 installed, see #32. Completely unrelated issue to what's happening on Mavericks.

[Wowfunhappy]

Okay, more wild theory time! As usual, everything could be completely wrong, I'm just looking at the code and trying to make some educated guesses.

I'm following the crash log from back when Chromium used to outright crash in #15, because the nice thing about crashes is they provide backtraces. There's a line:

17  org.chromium.Chromium.framework	0x0000000102a20f41 SkPictureData::CreateFromStream(SkStream*, SkPictInfo const&, SkDeserialProcs const&, SkTypefacePlayback*) + 81

Which should be referring to: https://github.com/blueboxd/skia/blob/3f7d9988616af2bf8085eeca77963236fee874c1/src/core/SkPictureData.cpp#L472

SkPictureData* SkPictureData::CreateFromStream(SkStream* stream,
                                               const SkPictInfo& info,
                                               const SkDeserialProcs& procs,
                                               SkTypefacePlayback* topLevelTFPlayback)

Based on my reading of the code in SkPicture::MakeFromStream, I believe that at the time SkPictureData::CreateFromStream is called, topLevelTFPlayback should still be nullptr. Which makes me wonder—when is topLevelTFPlayback supposed to become non-null, and is that in fact happening?

Well, it looks like it's supposed to be set here:

if (!topLevelTFPlayback) {
    topLevelTFPlayback = &data->fTFPlayback;
}

Coincidentally, there's a commit from three years ago which changed how fTFPlayback is set; it now uses "smart pointers" instead of "SkRefCnt_SafeAssign". I have no idea what any of that means, but it seems suspicious. The commit was also made in July of 2018, just a few months after Skia dropped Mavericks support.

Could that change be the source of the problem? Or am I just spouting gibberish?

Here's the Google page which may have more info on the commit: https://skia-review.googlesource.com/c/skia/+/140249/

[blueboxd]

Thanks!
I still don't know about SkPictureData, but is a smart pointer causing issue only on 10.9...?
I think some macOS API is the cause. 🤔
I'll revert that commit and confirm.

[Wowfunhappy]

but is a smart pointer causing issue only on 10.9...? I think some macOS API is the cause.

I mean, I don't know, but it piqued my interest because I was looking for something that seemed similar to #2. And #2 was a use-after-free bug caused by changes to pointer ownership in Skia.

[Wowfunhappy]

I decided to try probing this from a completely different angle. I used Chromium's print dialog to create PDFs of the "About Chromium" page on both Mountain Lion and Mavericks. Obviously, the Mountain Lion one has broken text, and the Mavericks one does not.

Mountain Lion.pdf
Mavericks.pdf

The first thing to notice is that the Mavericks PDF is almost twice the file size of the Mountain Lion one. What is in there?

I took a look with pdffonts, from the Xpdf command line tools:

$ ./pdffonts Mountain\ Lion.pdf 
name                                           type              emb sub uni prob object ID
---------------------------------------------- ----------------- --- --- --- ---- ---------
Times-Roman                                    CID TrueType      yes no  yes           4  0
Roboto-Regular                                 CID TrueType      yes no  yes           5  0
Desktop$ 

$ ./pdffonts Mavericks.pdf 
name                                           type              emb sub uni prob object ID
---------------------------------------------- ----------------- --- --- --- ---- ---------
[none]                                         Type 3            yes no  yes           4  0
[none]                                         Type 3            yes no  yes           5  0
[none]                                         Type 3            yes no  yes          18  0
Roboto-Regular                                 CID TrueType      yes no  yes          25  0

Well, that probably explains the file size difference—the Mavericks PDF seems to have four embedded fonts, whereas Mountain Lion only has two. Suspiciously, these fonts don't have a name, and they have a weird type, "Type 3". If the embedded font is what's corrupted, that would explain the broken glyphs!

Also interesting to me is that running ./pdftotext Mavericks.pdf creates a text file which contains all of the text which is illegible in the original PDF. So, the actual text is there!

[blueboxd]

Thanks for the investigation!

Finally, I got a culprit! 🧐
Q: Why only on Mavericks?
A: You wrote that.
https://github.com/blueboxd/skia/blob/e7368167b01830659a60ba1e896ae52789f7a2f5/src/ports/SkScalerContext_mac_ct.cpp#L757

if(isMavericks())
  return false;

We need to make SkScalerContext_Mac::generatePath (i.e. CTFontCreatePathForGlyph or equivalent) usable on Mavericks...
I'll investigate old Skia.

[blueboxd]

Hmm, the above patch is a workaround for #11, but Skia used in Chrome 65 calls CTFontCreatePathForGlyph the same way...
https://github.com/blueboxd/skia/blob/e201ebc995151adbe0e15cd88d7277d41c40ddbf/src/ports/SkFontHost_mac.cpp#L1278

In my environment, re-enabling SkScalerContext_Mac::generatePath fixes the printing issue and still does not crash.

@Wowfunhappy
Is r946471 still crashing?

[Wowfunhappy]

@Wowfunhappy
Is r946471 still crashing?

No, it's not crashing! And printing seems to work perfectly!

Edit: Oh, #11 was only on a handful of pages! Let me test more thoroughly for a few days before celebrating. Printing does work though!

[blueboxd]

@Wowfunhappy Thanks!
I close this issue at this time.
If #11 occurs, feel free to reopen #11.

[Wowfunhappy]

Hey @blueboxd, did this fix get left out of the "stable" branch somehow? I just installed the one from last night, and it looks like printing doesn't work.

[blueboxd]

Ah, sorry!
I forgot to merge the fix to the stable branch of skia.
Rebuilt and replaced the stable binary.