Some Type 1 fonts have some PostScript code at the start of the font
that checks if the font is already cached in the printer (based on the
font UniqueID key). This breaks our subsetted font as it is not the
same as the original font.
Checking for and removing a random blob of PostScript is difficult so
this patch takes the simpler approach of searching for the PS code
that checks if the UniqueID dictionary entry exists
ie
/UniqueID known
this code leaves the value "true" or "false" on the PS interpreter
stack depending on whether the "UniqueID" key exists.
Then the patch inserts the PS code " pop false " after the above code
to remove the old result and place "false" on the stack to make it
appear that UniqueID does not exist.
This approach should be able to handle any type of PostScript code
that attempts to do something with the UniqueID value in the font
dictionary.
This ensures that PS/PDF output is always the same for the same cairo
input. Previously the order of the embedded fonts depended on the hash
key of the fonts which depended on the memory location of fonts.
In the eexec encryption used in Type 1 fonts, the first four bytes of
ciphertext must not start with a white space character or contain an
ASCII Hex character. Some fonts do not comply with this
restriction. This may cause problems for some PDF consumers.
Fix this by overwriting the four random bytes at the start of the
decrypted cleartext with spaces. When re-encrypted the first four
bytes of ciphertext will always be 0xf0, 0x83, 0xef, 0x00 which
complies with the restrictions.
These are all perfectly correct code. Most are simply there because when
we support vertical text writing mode we need to update there, but that's
pretty trivial. No special markers needed.
/me is trying to make user-font clean of XXX and TODO marks
Someone reported on cairo list that on some system with gcc, he had the
compile-time assertion failing, meaning that the following struct:
typedef struct {
unsigned long index;
union {
struct {
double x;
double y;
} d;
struct {
int x;
int y;
} i;
} p;
} cairo_xlib_glyph_t;
had a different size from:
typedef struct {
unsigned long index;
double x;
double y;
} cairo_glyph_t;
That looks quite a weird thing for a compiler to do. Anyway, rewriting
our struct like this may help in those weird situations:
typedef union {
cairo_glyph_t d;
unsigned long index;
struct {
unsigned long index;
int x;
int y;
} i;
} cairo_xlib_glyph_t;
That's what we do now.
This way the same callback code can be used to render multiple different
glyph arrays. Change done for education purposes, otherwise doesn't
make any difference in the test.
Essentially renaming cairo-mutex-type-private.h to cairo-mutex-impl-private.h
and changing all its namespace from cairo_mutex to cairo_mutex_impl.
cairo-mutex-type-private.h then does all the sanity checks on the
implementation that used to be in cairo-mutex-private.h. Plus, defines macros
for the cairo-mutex namespace to map to the cairo-mutex-impl namespace. This
extra mapping layer allows for add debugging facilities.
