Inkscape fonts artifact pdf#
Inkscape fonts artifact update#

Inkscape fonts artifact pdf#

Maybe we could create some kind of alternative path (maybe a new internal printing API) that pdf.js can use for printing, which causes it to re-render the PDF to a printing context instead of the canvas bitmap context.

When we then ask Firefox to print, all it has to work with is that rasterized (screen-resolution) bitmap we don't have a mechanism to go back to the original drawing operations (derived from the original PDF) and re-execute those on a different (higher-resolution or vector-based) target. So pdf.js renders the original (structured, vector-based) PDF to a canvas rendering context, generating a full-page rasterized image, which is what we see on the screen. Right - as currently implemented, there is no other way to print it because whatever is rendered to a element exists only as a bitmap image AFAIK we don't record the drawing operations that go to make up a canvas image, they're just executed immediately. So I would expect a 'good' save-to-pdf path to preserve this, not to convert the glyphs to paths (which will most likely lose lots of accessibility etc compared to having actual text in the document). the original PDF generated by GDocs contains the text as text objects, with an embedded (subset) Arial font to render them. I didn't manage to reproduce with my personal printer (Brother) on windows 11 but I printed it in using Save to PDF, Microsoft Print to PDF and Adobe print.īoth Microsoft and Adobe are generating some paths (set of Bezier curves for each glyph) and Save is rasterizing the content and then put the image into a pdf. (In reply to Calixte Denizet (:calixte) from comment #14) My current guess is that somewhere inside cairo, we're encountering an error or unsupported case that causes the library to fall back to simple rasterization instead of generating vector output.

Inkscape fonts artifact update#

It sounds like the cairo update in bug 739096 may be responsible for this, but offhand I don't know why.

So we need to figure out why the canvas is being rasterized and printed (or saved to PDF) as an image.

When we then print that document, the entire pdf.js canvas is printed as a raster image hence the poor rendering. When the user asks GDocs to print, it appears to first generate a PDF version of the document (server-side), which Firefox displays using pdf.js, which renders it to a. It looks to me like Emilio's comment 3 is key here.