1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-07-25 00:27:35 +00:00
serenity/Userland/Libraries/LibPDF/Fonts
Rodrigo Tobar 1b90ea7d3a LibPDF: Augment Type11FontProgram with Type2 capabilities
The Type1FontProgram logic was based on the Adobe Type 1 Font Format; in
particular, it implemented the CharStrings Dictionary section
(charstring decoding, and most commands). In the case of Type1, these
charstrings are read from a PS1 diciontary, with one entry per character
in the font's charset. This has served us well for Type1 font rendering.

When implementing Type1C font rendering, this wasn't enough. Type1C PDF
fonts are specified in embedded CFF (Compact Font File) streams, which
also contain a charstring dictionary with an entry for each character in
the font's charset. These entries can be slightly different from those
in a PS1 Font Program though: depending on a flag in the CFF, the
entries will be encoded either in the original charstring format from
the Adobe Type 1 Font Format, or in the "Type 2 Charstring Format"
(Adobe's Technical Note #1577). This new format is for the most part a
super-set of the original, with small differences, all in the name of
making the representation as compact as possible:

 * The glyph's width is not specified via a separate command; instead
   it's an optional additional argument to the first command of the
   charstring stream (and even then, it's only the *difference* to a
   nominal character width specified in the CFF).
 * The interpretation of a 4-byte number is different from Type 1: in
   Type 1 this is a 4-byte unsigned integer, whereas in Type 1 it's a
   fixed decimal with 16 bits of fractional part.
 * Many commands accept a variable set of arguments, so they can draw
   more than one line/curve on a single go. These are all
   retro-compatible with Type 1's commands.

All these changes are implemented in this patch in a
backwards-compatible way. To ensure Type 1/2 behavior is accessed, a new
parameter indicates which behavior is desired when decoding the
charstring stream.

I also took the chance to centralise some logic that was previously
duplicated across the parse_glyph function. Common lambdas capture the
logic for moving to, or drawing a line/curve to a given point and
updating the glyph state. Similarly, some command logic, including
reading parameters, are shared by several commands. Finally, I've
re-organised the cases in the main switch to group together related
commands.
2023-01-25 15:40:11 +01:00
..
PDFFont.cpp LibPDF: Record base font name read from document 2023-01-25 15:40:11 +01:00
PDFFont.h LibPDF: Record base font name read from document 2023-01-25 15:40:11 +01:00
PS1FontProgram.cpp LibPDF: Augment Type11FontProgram with Type2 capabilities 2023-01-25 15:40:11 +01:00
PS1FontProgram.h LibPDF: Remove unused member 2023-01-25 15:40:11 +01:00
TrueTypeFont.cpp LibPDF: Avoid reading fields from moved-from Data object 2023-01-25 15:40:11 +01:00
TrueTypeFont.h LibPDF: Record base font name read from document 2023-01-25 15:40:11 +01:00
Type0Font.cpp LibPDF: Move all font handling to Type1Font and TrueTypeFont classes 2022-11-25 22:44:47 +01:00
Type0Font.h LibPDF: Record base font name read from document 2023-01-25 15:40:11 +01:00
Type1Font.cpp LibPDF: Add new Type1FontProgram base class 2023-01-25 15:40:11 +01:00
Type1Font.h LibPDF: Add new Type1FontProgram base class 2023-01-25 15:40:11 +01:00
Type1FontProgram.cpp LibPDF: Augment Type11FontProgram with Type2 capabilities 2023-01-25 15:40:11 +01:00
Type1FontProgram.h LibPDF: Augment Type11FontProgram with Type2 capabilities 2023-01-25 15:40:11 +01:00