Comment 50 for bug 277404

> We have a problem then, there can be three buggy compoments:

> * both poppler and gs have "the same bug" and the two errors team
> up to end up doing correct rendering

The gs level3 postscript is in fact level2 postscript with just a couple
of names changed:

:; diff -U0 d00022-001-gs-l2.ps d00022-001-gs-l3.ps
--- d00022-001-gs-l2.ps 2009-03-17 03:39:27.497318352 -0400
+++ d00022-001-gs-l3.ps 2009-03-17 03:39:27.980322026 -0400
@@ -9 +9 @@
-%%LanguageLevel: 2
+%%LanguageLevel: 3
@@ -14,2 +14,2 @@
-%%BeginResource: procset GS_pswrite_2_0_1001 1.001 0
-/GS_pswrite_2_0_1001 80 dict dup begin
+%%BeginResource: procset GS_pswrite_3_0_1001 1.001 0
+/GS_pswrite_3_0_1001 80 dict dup begin
@@ -63 +63 @@
-GS_pswrite_2_0_1001 begin
+GS_pswrite_3_0_1001 begin

So the fact that gs's output prints on the HP is not really relevant.

This difference between poppler’s l2 and l3 output in this case (the PDF
uses DejaVuSans and DejaVuSansMono as its fonts) is that the l3 creates
CID keyed fonts whereas the l2 does not.

So, either the HP cannot handle CID-keyed type42 fonts, or the generated
CID fonts are buggy.

In any case, it is xpdf code that is different between l2 and l3 and the
primary difference is the use of CID keyed fonts when the PDF uses them.

Stated another way, the difference is the use of pdfMakeFont16L3 rather
than pdfMakeFont16 iff the font is CID keyed in the src PDF.

-JimC