Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(590)

Unified Diff: site/dev/design/pdftheory.md

Issue 849133002: convert pdf design document to markdown (Closed) Base URL: https://skia.googlesource.com/skia.git@master
Patch Set: Another Patch Set Created 5 years, 11 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
« no previous file with comments | « site/dev/design/index.md ('k') | site/user/sample/pdf.md » ('j') | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
Index: site/dev/design/pdftheory.md
diff --git a/site/dev/design/pdftheory.md b/site/dev/design/pdftheory.md
new file mode 100644
index 0000000000000000000000000000000000000000..2a24ea74ffc3bbca966be5aec04264b10e94ed38
--- /dev/null
+++ b/site/dev/design/pdftheory.md
@@ -0,0 +1,595 @@
+PDF Theory of Operation
+=======================
+
+<!--
+PRE-GIT DOCUMENT VERSION HISTORY
+ 2012-06-25 Steve VanDeBogart
+ * Original version
+ 2015-01-14 Hal Canary.
+ * Add section "Using the PDF backend"
+ * Markdown formatting
+-->
+
+
+To make use of Skia's PDF backend, see
+[Using Skia's PDF Backend](../../user/sample/pdf).
+
+Internally, Skia uses SkPDFDocument and SkPDFDevice to represent PDF
+documents and pages. This document describes how the backend
+operates, but **these interfaces are not part of the public API and
+are subject to perpetual change.**
+
+* * *
+
+### Contents ###
+
+* [Typical usage of the PDF backend](#Typical_usage_of_the_PDF_backend)
+* [PDF Objects and Document Structure](#PDF_Objects_and_Document_Structure)
+* [PDF drawing](#PDF_drawing)
+* [Interned objects](#Interned_objects)
+* [Graphic States](#Graphic_States)
+* [Clip and Transform](#Clip_and_Transform)
+* [Generating a content stream](#Generating_a_content_stream)
+* [Margins and content area](#Margins_and_content_area)
+* [Drawing details](#Drawing_details)
+ + [Layers](#Layers)
+ + [Fonts](#Fonts)
+ + [Shaders](#Shaders)
+ + [Xfer modes](#Xfer_modes)
+* [Known issues](#Known_issues)
+
+<a name="Typical_usage_of_the_PDF_backend"></a>
+Typical usage of the PDF backend
+--------------------------------
+
+SkPDFDevice is the main interface to the PDF backend. This child of
+SkDevice can be set on an SkCanvas and drawn to. It requires no more
+care and feeding than SkDevice. Once drawing is complete, the device
+should be added to an SkPDFDocument as a page of the desired PDF. A
+new SkPDFDevice should be created for each page desired in the
+document. After all the pages have been added to the document,
+`SkPDFDocument::emitPDF()` can be called to get a PDF file. One of the
+special features of the PDF backend is that the same device can be
+added to multiple documents. This for example, would let you generate
+a PDF with the single page you just drew as well as adding it to a
+longer document with a bunch of other pages.
+
+ SkAutoUnref<SkPDFDevice> pdfDevice(
+ new SkPDFDevice(width, height, initial_transform));
+
+ SkCanvas canvas(pdfDevice);
+ draw_content(&canvas);
+
+ SkPDFDocument doc;
+ doc.appendPage(dev);
+ doc.emitPDF(&pdf_stream);
+
+<a name="PDF_Objects_and_Document_Structure"></a>
+PDF Objects and Document Structure
+----------------------------------
+
+**Background**: The PDF file format has a header, a set of objects and
+then a footer that contains a table of contents for all of the objects
+in the document (the cross-reference table). The table of contents
+lists the specific byte position for each object. The objects may have
+references to other objects and the ASCII size of those references is
+dependent on the object number assigned to the referenced object;
+therefore we can’t calculate the table of contents until the size of
+objects is known, which requires assignment of object
+numbers.
+
+Furthermore, PDF files can support a *linearized* mode, where objects
+are in a specific order so that pdf-viewers can more easily retrieve
+just the objects they need to display a specific page, i.e. by
+byte-range requests over the web. Linearization also requires that all
+objects used or referenced on the first page of the PDF have object
+numbers before the rest of the objects. Consequently, before
+generating a linearized PDF, all objects, their sizes, and object
+references must be known. Skia has no plans to implement linearized
+PDFs.
+
+<!-- <del>At this point, linearized PDFs are not generated. The
+framework to generate them is in place, but the final bits of code
+have not been written.</del> -->
+
+ %PDF-1.4
+ …objects...
+ xref
+ 0 31 % Total number of entries in the table of contents.
+ 0000000000 65535 f
+ 0000210343 00000 n
+ …
+ 0000117055 00000 n
+ trailer
+ <</Size 31 /Root 1 0 R>>
+ startxref
+ 210399 % Byte offset to the start of the table of contents.
+ %%EOF
+
+The class SkPDFCatalog and the virtual class SkPDFObject are used to
+manage the needs of the file format. Any object that will represent a
+PDF object must inherit from SkPDFObject and implement the methods to
+generate the binary representation and report any other SkPDFObjects
+used as resources. SkPDFTypes.h defines most of the basic PDF objects
+types: bool, int, scalar, string, name, array, dictionary, and object
+reference. The stream type is defined in SkPDFStream.h. A stream is a
+dictionary containing at least a Length entry followed by the data of
+the stream. All of these types except the stream type can be used in
+both a direct and an indirect fashion, i.e. an array can have an int
+or a dictionary as an inline entry, which does not require an object
+number. The stream type, cannot be inlined and must be referred to
+with an object reference. Most of the time, other objects types can be
+referred to with an object reference, but there are specific rules in
+the PDF specification that requires an inline reference in some place
+or an indirect reference in other places. All indirect objects must
+have an object number assigned.
+
+* **bools**: `true` `false`
+* **ints**: `42` `0` `-1`
+* **scalars**: `0.001`
+* **strings**: `(strings are in parentheses or byte encoded)` `<74657374>`
+* **name**: `/Name` `/Name#20with#20spaces`
+* **array**: `[/Foo 42 (arrays can contain multiple types)]`
+* **dictionary**: `<</Key1 (value1) /key2 42>>`
+* **indirect object**:
+ `5 0 obj
+ (An indirect string. Indirect objects have an object number and a
+ generation number, Skia always uses generation 0 objects)
+ endobj`
+* **object reference**: `5 0 R`
+* **stream**: `<</Length 56>>
+ stream
+ ...stream contents can be arbitrary, including binary...
+ endstream`
+
+The PDF backend requires all indirect objects used in a PDF to be
+added to the SkPDFCatalog of the SkPDFDocument. The catalog is
+responsible for assigning object numbers and generating the table of
+contents required at the end of PDF files. In some sense, generating a
+PDF is a three step process. In the first step all the objects and
+references among them are created (mostly done by SkPDFDevice). In the
+second step, object numbers are assigned and SkPDFCatalog is informed
+of the file offset of each indirect object. Finally, in the third
+step, the header is printed, each object is printed, and then the
+table of contents and trailer are printed. SkPDFDocument takes care of
+collecting all the objects from the various SkPDFDevice instances,
+adding them to an SkPDFCatalog, iterating through the objects once to
+set their file positions, and iterating again to generate the final
+PDF.
+
+ %PDF-1.4
+ 2 0 obj <<
+ /Type /Catalog
+ /Pages 1 0 R
+ >>
+ endobj
+ 3 0 obj <<
+ /Type /Page
+ /Parent 1 0 R
+ /Resources <>
+ /MediaBox [0 0 612 792]
+ /Contents 4 0 R
+ >>
+ endobj
+ 4 0 obj <> stream
+ endstream
+ endobj
+ 1 0 obj <<
+ /Type /Pages
+ /Kids [3 0 R]
+ /Count 1
+ >>
+ endobj
+ xref
+ 0 5
+ 0000000000 65535 f
+ 0000000236 00000 n
+ 0000000009 00000 n
+ 0000000062 00000 n
+ 0000000190 00000 n
+ trailer
+ <</Size 5 /Root 2 0 R>>
+ startxref
+ 299
+ %%EOF
+
+<a name="PDF_drawing"></a>
+PDF drawing
+-----------
+
+Most drawing in PDF is specified by the text of a stream, referred to
+as a content stream. The syntax of the content stream is different
+than the syntax of the file format described above and is much closer
+to PostScript in nature. The commands in the content stream tell the
+PDF interpreter to draw things, like a rectangle (`x y w h re`), an
+image, or text, or to do meta operations like set the drawing color,
+apply a transform to the drawing coordinates, or clip future drawing
+operations. The page object that references a content stream has a
+list of resources that can be used in the content stream using the
+dictionary name to reference the resources. Resources are things like
+font objects, images objects, graphic state objects (a set of meta
+operations like miter limit, line width, etc). Because of a mismatch
+between Skia and PDF’s support for transparency (which will be
+explained later), SkPDFDevice records each drawing operation into an
+internal structure (ContentEntry) and only when the content stream is
+needed does it flatten that list of structures into the final content
+stream.
+
+ 4 0 obj <<
+ /Type /Page
+ /Resources <<
+ /Font <</F1 9 0 R>>
+ /XObject <</Image1 22 0 R /Image2 73 0 R>>
+ >>
+ /Content 5 0 R
+ >> endobj
+
+ 5 0 obj <</Length 227>> stream
+ % In the font specified in object 9 and a height
+ % of 12 points, at (72, 96) draw ‘Hello World.’
+ BT
+ /F1 12 Tf
+ 72 96 Td
+ (Hello World) Tj
+ ET
+ % Draw a filled rectange.
+ 200 96 72 72 re B
+ ...
+ endstream
+ endobj
+
+<a name="Interned_objects"></a>
+Interned objects
+----------------
+
+There are a number of high level PDF objects (like fonts, graphic
+states, etc) that are likely to be referenced multiple times in a
+single PDF. To ensure that there is only one copy of each object
+instance these objects an implemented with an
+[interning pattern](http://en.wikipedia.org/wiki/String_interning).
+As such, the classes representing these objects (like
+SkPDFGraphicState) have private constructors and static methods to
+retrieve an instance of the class. Internally, the class has a list of
+unique instances that it consults before returning a new instance of
+the class. If the requested instance already exists, the existing one
+is returned. For obvious reasons, the returned instance should not be
+modified. A mechanism to ensure that interned classes are immutable is
+needed. See [issue 2683](http://skbug.com/2683).
+
+<a name="Graphic_States"></a>
+Graphic States
+--------------
+
+PDF has a number of parameters that affect how things are drawn. The
+ones that correspond to drawing options in Skia are: color, alpha,
+line cap, line join type, line width, miter limit, and xfer/blend mode
+(see later section for xfer modes). With the exception of color, these
+can all be specified in a single pdf object, represented by the
+SkPDFGraphicState class. A simple command in the content stream can
+then set the drawing parameters to the values specified in that
+graphic state object. PDF does not allow specifying color in the
+graphic state object, instead it must be specified directly in the
+content stream. Similarly the current font and font size are set
+directly in the content stream.
+
+ 6 0 obj <<
+ /Type /ExtGState
+ /CA 1 % Opaque - alpha = 1
+ /LC 0 % Butt linecap
+ /LJ 0 % Miter line-join
+ /LW 2 % Line width of 2
+ /ML 6 % Miter limit of 6
+ /BM /Normal % Blend mode is normal i.e. source over
+ >>
+ endobj
+
+<a name="Clip_and_Transform"></a>
+Clip and Transform
+------------------
+
+Similar to Skia, PDF allows drawing to be clipped or
+transformed. However, there are a few caveats that affect the design
+of the PDF backend. PDF does not support perspective transforms
+(perspective transform are treated as identity transforms). Clips,
+however, have more issues to cotend with. PDF clips cannot be directly
+unapplied or expanded. i.e. once an area has been clipped off, there
+is no way to draw to it. However, PDF provides a limited depth stack
+for the PDF graphic state (which includes the drawing parameters
+mentioned above in the Graphic States section as well as the clip and
+transform). Therefore to undo a clip, the PDF graphic state must be
+pushed before the clip is applied, then popped to revert to the state
+of the graphic state before the clip was applied.
+
+As the canvas makes drawing calls into SkPDFDevice, the active
+transform, clip region, and clip stack are stored in a ContentEntry
+structure. Later, when the ContentEntry structures are flattened into
+a valid PDF content stream, the transforms and clips are compared to
+decide on an efficient set of operations to transition between the
+states needed. Currently, a local optimization is used, to figure out
+the best transition from one state to the next. A global optimization
+could improve things by more effectively using the graphics state
+stack provided in the PDF format.
+
+<a name="Generating_a_content_stream"></a>
+Generating a content stream
+---------------------------
+
+For each draw call on an SkPDFDevice, a new ContentEntry is created,
+which stores the matrix, clip region, and clip stack as well as the
+paint parameters. Most of the paint parameters are bundled into an
+SkPDFGraphicState (interned) with the rest (color, font size, etc)
+explicitly stored in the ContentEntry. After populating the
+ContentEntry with all the relevant context, it is compared to the the
+most recently used ContentEntry. If the context matches, then the
+previous one is appended to instead of using the new one. In either
+case, with the context populated into the ContentEntry, the
+appropriate draw call is allowed to append to the content stream
+snippet in the ContentEntry to affect the core of the drawing call,
+i.e. drawing a shape, an image, text, etc.
+
+When all drawing is complete, SkPDFDocument::emitPDF() will call
+SkPDFDevice::content() to request the complete content stream for the
+page. The first thing done is to apply the initial transform specified
+in part in the constructor, this transform takes care of changing the
+coordinate space from an origin in the lower left (PDF default) to the
+upper left (Skia default) as well as any translation or scaling
+requested by the user (i.e. to achieve a margin or scale the
+canvas). Next (well almost next, see the next section), a clip is
+applied to restrict drawing to the content area (the part of the page
+inside the margins) of the page. Then, each ContentEntry is applied to
+the content stream with the help of a helper class, GraphicStackState,
+which tracks the state of the PDF graphics stack and optimizes the
+output. For each ContentEntry, commands are emitted to the final
+content entry to update the clip from its current state to the state
+specified in the ContentEntry, similarly the Matrix and drawing state
+(color, line joins, etc) are updated, then the content entry fragment
+(the actual drawing operation) is appended.
+
+<a name="Margins_and_content_area"></a>
+Margins and content area
+------------------------
+
+The above procedure does not permit drawing in the margins. This is
+done in order to contain any rendering problems in WebKit. In order to
+support headers and footers, which are drawn in the margin, a second
+set of ContentEntry’s are maintained. The
+methodSkPDFDevice::setDrawingArea() selects which set of
+ContentEntry’s are drawn into. Then, in the SkPDFDevice::content()
+method, just before the clip to the content area is applied the margin
+ContentEntry's are played back.
+
+<!-- TODO(halcanary): update this documentation. -->
+
+<a name="Drawing_details"></a>
+Drawing details
+---------------
+
+Certain objects have specific properties that need to be dealt
+with. Images, layers (see below), and fonts assume the standard PDF
+coordinate system, so we have to undo any flip to the Skia coordinate
+system before drawing these entities. We don’t currently support
+inverted paths, so filling an inverted path will give the wrong result
+([issue 241](http://skbug.com/241)). PDF doesn’t draw zero length
+lines that have butt of square caps, so that is emulated.
+
+<a name="Layers"></a>
+### Layers ###
+
+PDF has a higher level object called a form x-object (form external
+object) that is basically a PDF page, with resources and a content
+stream, but can be transformed and drawn on an existing page. This is
+used to implement layers. SkDevice has a method,
+createFormXObjectFromDevice, which uses the SkPDFDevice::content()
+method to construct a form x-object from the the
+device. SkPDFDevice::drawDevice() works by creating a form x-object of
+the passed device and then drawing that form x-object in the root
+device. There are a couple things to be aware of in this process. As
+noted previously, we have to be aware of any flip to the coordinate
+system - flipping it an even number of times will lead to the wrong
+result unless it is corrected for. The SkClipStack passed to drawing
+commands includes the entire clip stack, including the clipping
+operations done on the base layer. Since the form x-object will be
+drawn as a single operation onto the base layer, we can assume that
+all of those clips are in effect and need not apply them within the
+layer.
+
+<a name="Fonts"></a>
+### Fonts ###
+
+There are many details for dealing with fonts, so this document will
+only talk about some of the more important ones. A couple short
+details:
+
+* We can’t assume that an arbitrary font will be available at PDF view
+ time, so we embed all fonts in accordance with modern PDF
+ guidelines.
+* Most fonts these days are TrueType fonts, so this is where most of
+ the effort has been concentrated.
+* Because Skia may only be given a glyph-id encoding of the text to
+ render and there is no perfect way to reverse the encoding, the
+ PDF backend always uses the glyph-id encoding of the text.
+
+#### *Type1/Type3 fonts* ####
+
+Linux supports Type1 fonts, but Windows and Mac seem to lack the
+functionality required to extract the required information from the
+font without parsing the font file. When a non TrueType font is used
+any any platform (except for Type1 on Linux), it is encoded as a Type3
+font. In this context, a Type3 font is an array of form x-objects
+(content streams) that draw each glyph of the font. No hinting or
+kerning information is included in a Type3 font, just the shape of
+each glyph. Any font that has the do-not embed copy protection bit set
+will also get embedded as a Type3 font. From what I understand, shapes
+are not copyrightable, but programs are, so by stripping all the
+programmatic information and only embedding the shape of the glyphs we
+are honoring the do-not embed bit as much as required by law.
+
+PDF only supports an 8-bit encoding for Type1 or Type3 fonts. However,
+they can contain more than 256 glyphs. The PDF backend handles this by
+segmenting the glyphs into groups of 255 (glyph id 0 is always the
+unknown glyph) and presenting the font as multiple fonts, each with up
+to 255 glyphs.
+
+#### *Font subsetting* ####
+
+Many fonts, especially fonts with CJK support are fairly large, so it
+is desirable to subset them. Chrome uses the SFNTLY package to provide
+subsetting support to Skia for TrueType fonts. However, there is a
+conflict between font subsetting and interned objects. If the object
+is immutable, how can it be subsetted? This conflict is resolved by
+using a substitution mechanism in SkPDFCatalog. Font objects are still
+interned, but the interned objects aren’t internally
+populated. Subsetting starts while drawing text to an SkPDFDevice; a
+bit set indicating which glyphs have been used is maintained. Later,
+when SkPDFDocument::emitPDF() is rendering the PDF, it queries each
+device (each page) for the set of fonts used and the glyphs used from
+each font and combines the information. It then asks the interned
+(unpopulated) font objects to create a populated instance with the
+calculated subset of the font - this instance is not interned. The
+subsetted instance is then set as a substitute for the interned font
+object in the SkPDFCatalog. All future references to those fonts
+within that document will refer to the subsetted instances, resulting
+in a final PDF with exactly one instance of each used font that
+includes only the glyphs used.
+
+The substitution mechanism is a little complicated, but is needed to
+support the use case of an SkPDFDevice being added to multiple
+documents. If fonts were subsetted in-situ, concurrent PDF generation
+would have to be explicitly handled. Instead, by giving each document
+its own subsetted instance, there is no need to worry about concurrent
+PDF generation. The substitution method is also used to support
+optional stream compression. A stream can used by different documents
+in both a compressed and uncompressed form, leading to the same
+potential difficulties faced by the concurrent font use case.
+
+<a name="Shaders"></a>
+### Shaders ###
+
+Skia has two types of predefined shaders, image shaders and gradient
+shaders. In both cases, shaders are effectively positioned absolutely,
+so the initial position and bounds of where they are visible is part
+of the immutable state of the shader object. Each of the Skia’s tile
+modes needs to be considered and handled explicitly. The image shader
+we generate will be tiled, so tiling is handled by default. To support
+mirroring, we draw the image, reversed, on the appropriate axis, or on
+both axes plus a fourth in the vacant quadrant. For clamp mode, we
+extract the pixels along the appropriate edge and stretch the single
+pixel wide/long image to fill the bounds. For both x and y in clamp
+mode, we fill the corners with a rectangle of the appropriate
+color. The composed shader is then rotated or scaled as appropriate
+for the request.
+
+Gradient shaders are handled purely mathematically. First, the matrix
+is transformed so that specific points in the requested gradient are
+at pre-defined locations, for example, the linear distance of the
+gradient is always normalized to one. Then, a type 4 PDF function is
+created that achieves the desired gradient. A type 4 function is a
+function defined by a resticted postscript language. The generated
+functions clamp at the edges so if the desired tiling mode is tile or
+mirror, we hav to add a bit more postscript code to map any input
+parameter into the 0-1 range appropriately. The code to generate the
+postscript code is somewhat obtuse, since it is trying to generate
+optimized (for space) postscript code, but there is a significant
+number of comments to explain the intent.
+
+<a name="Xfer_modes"></a>
+### Xfer modes ###
+
+PDF supports some of the xfer modes used in Skia directly. For those,
+it is simply a matter of setting the blend mode in the graphic state
+to the appropriate value (Normal/SrcOver, Multiply, Screen, Overlay,
+Darken, Lighten, !ColorDOdge, ColorBurn, HardLight, SoftLight,
+Difference, Exclusion). Aside from the standard SrcOver mode, PDF does
+not directly support the porter-duff xfer modes though. Most of them
+(Clear, SrcMode, DstMode, DstOver, SrcIn, DstIn, SrcOut, DstOut) can
+be emulated by various means, mostly by creating form x-objects out of
+part of the content and drawing it with a another form x-object as a
+mask. I have not figured out how to emulate the following modes:
+SrcATop, DstATop, Xor, Plus.
+
+At the time of writing [2012-06-25], I have a [CL outstanding to fix a
+misunderstanding I had about the meaning of some of the emulated
+modes](https://codereview.appspot.com/4631078/).
+I will describe the system with this change applied.
+
+First, a bit of terminology and definition. When drawing something
+with an emulated xfer mode, what’s already drawn to the device is
+called the destination or Dst, and what’s about to be drawn is the
+source or Src. Src (and Dst) can have regions where it is transparent
+(alpha equals zero), but it also has an inherent shape. For most kinds
+of drawn objects, the shape is the same as where alpha is not
+zero. However, for things like images and layers, the shape is the
+bounds of the item, not where the alpha is non-zero. For example, a
+10x10 image, that is transparent except for a 1x1 dot in the center
+has a shape that is 10x10. The xfermodes gm test demonstrates the
+interaction between shape and alpha in combination with the port-duff
+xfer modes.
+
+The clear xfer mode removes any part of Dst that is within Src’s
+shape. This is accomplished by bundling the current content of the
+device (Dst) into a single entity and then drawing that with the
+inverse of Src’s shape used as a mask (we want Dst where Src
+isn’t). The implementation of that takes a couple more steps. You may
+have to refer back to [the content stream section](#Generating_a_content_stream). For any draw call, a
+ContentEntry is created through a method called
+SkPDFDevice::setUpContentEntry(). This method examines the xfer modes
+in effect for that drawing operation and if it is an xfer mode that
+needs emulation, it creates a form x-object from the device,
+i.e. creates Dst, and stores it away for later use. This also clears
+all of that existing ContentEntry's on that device. The drawing
+operation is then allowed to proceed as normal (in most cases, see
+note about shape below), but into the now empty device. Then, when the
+drawing operation in done, a complementary method is
+called,SkPDFDevice::finishContentEntry(), which takes action if the
+current xfer mode is emulated. In the case of Clear, it packages what
+was just drawn into another form x-object, and then uses the Src form
+x-object, an invert function, and the Dst form x-object to draw Dst
+with the inverse shape of Src as a mask. This works well when the
+shape of Src is the same as the opaque part of the drawing, since PDF
+uses the alpha channel of the mask form x-object to do masking. When
+shape doesn’t match the alpha channel, additional action is
+required. The drawing routines where shape and alpha don’t match, set
+state to indicate the shape (always rectangular), which
+finishContentEntry uses. The clear xfer mode is a special case; if
+shape is needed, then Src isn’t used, so there is code to not bother
+drawing Src if shape is required and the xfer mode is clear.
+
+SrcMode is clear plus Src being drawn afterward. DstMode simply omits
+drawing Src. DstOver is the same as SrcOver with Src and Dst swapped -
+this is accomplished by inserting the new ContentEntry at the
+beginning of the list of ContentEntry’s in setUpContentEntry instead
+of at the end. SrcIn, SrcOut, DstIn, DstOut are similar to each, the
+difference being an inverted or non-inverted mask and swapping Src and
+Dst (or not). SrcIn is SrcMode with Src drawn with Dst as a
+mask. SrcOut is like SrcMode, but with Src drawn with an inverted Dst
+as a mask. DstIn is SrcMode with Dst drawn with Src as a
+mask. Finally, DstOut is SrcMode with Dst draw with an inverted Src as
+a mask.
+
+<a name="Known_issues"></a>
+Known issues
+------------
+
+* [issue 241](http://skbug.com/241)
+ As previously noted, a boolean geometry library
+ would improve clip fidelity in some places, add supported for
+ inverted fill types, as well as simplify code.
+ This is fixed, but behind a flag until path ops is production ready.
+* [issue 237](http://skbug.com/237)
+ SkMaskFilter is not supported.
+* [issue 238](http://skbug.com/238)
+ SkColorFilter is not supported.
+* [issue 249](http://skbug.com/249)
+ SrcAtop Xor, and Plus xfer modes are not supported.
+* [issue 240](http://skbug.com/240)
+ drawVerticies is not implemented.
+* [issue 244](http://skbug.com/244)
+ Mostly, only TTF fonts are directly supported. (User metrics
+ show that almost all fonts are truetype.
+* [issue 260](http://skbug.com/260)
+ Page rotation is accomplished by specifying a different
+ size page instead of including the appropriate rotation
+ annotation.
+
+* * *
+
« no previous file with comments | « site/dev/design/index.md ('k') | site/user/sample/pdf.md » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698