diff options
| -rw-r--r-- | experimental/GLFWTest/README.txt | 6 | ||||
| -rw-r--r-- | site/dev/contrib/style.md | 10 | ||||
| -rw-r--r-- | site/dev/design/pdftheory.md | 28 | ||||
| -rw-r--r-- | site/dev/sheriffing/index.md | 2 | ||||
| -rw-r--r-- | site/user/sample/color.md | 2 |
5 files changed, 24 insertions, 24 deletions
diff --git a/experimental/GLFWTest/README.txt b/experimental/GLFWTest/README.txt index 2be3f24940..dd2b4ea29b 100644 --- a/experimental/GLFWTest/README.txt +++ b/experimental/GLFWTest/README.txt @@ -1,6 +1,6 @@ -This test is Mac-only for now. Adding Linux or Win support shouldn’t be that difficult — it just needs a project file. +This test is Mac-only for now. Adding Linux or Win support shouldn't be that difficult — it just needs a project file. -To run this demo, you’ll need to do three things: -1) Get GLFW 3.1.1 or later, and install it at third_party/externals/glfw. You’ll need to run ‘cmake’ in that directory to build the makefiles, and then ‘make’ to build the libglfw.a library. +To run this demo, you'll need to do three things: +1) Get GLFW 3.1.1 or later, and install it at third_party/externals/glfw. You'll need to run ‘cmake’ in that directory to build the makefiles, and then ‘make’ to build the libglfw.a library. 2) Build the skia libraries via the command line (by running ‘ninja -C out/<config> dm’, for example. 3) Get a ship.png file. Place it in this directory. diff --git a/site/dev/contrib/style.md b/site/dev/contrib/style.md index 639738c28f..17989b3c82 100644 --- a/site/dev/contrib/style.md +++ b/site/dev/contrib/style.md @@ -2,7 +2,7 @@ Coding Style Guidelines ======================= These conventions have evolved over time. Some of the earlier code in both -projects doesn’t strictly adhere to the guidelines. However, as the code evolves +projects doesn't strictly adhere to the guidelines. However, as the code evolves we hope to make the existing code conform to the guildelines. Files @@ -11,8 +11,8 @@ Files We use .cpp and .h as extensions for c++ source and header files. We use foo_impl.h for headers with inline definitions for class foo. -Headers that aren’t meant for public consumption should be placed in src -directories so that they aren’t in a client’s search path. +Headers that aren't meant for public consumption should be placed in src +directories so that they aren't in a client's search path. We prefer to minimize includes. If forward declaring a name in a header is sufficient then that is preferred to an include. @@ -41,7 +41,7 @@ Naming ------ Both projects use a prefix to designate that they are Skia prefix for classes, -enums, structs, typedefs etc is Sk. Ganesh’s is Gr. Nested types should not be +enums, structs, typedefs etc is Sk. Ganesh's is Gr. Nested types should not be prefixed. <!--?prettify?--> @@ -184,7 +184,7 @@ Skia tends to use #ifdef SK_MACRO for boolean flags. Braces ------ -Open braces don’t get a newline. “else” and “else if” appear on same line as +Open braces don't get a newline. “else” and “else if” appear on same line as opening and closing braces unless preprocessor conditional compilation interferes. Braces are always used with if, else, while, for, and do. diff --git a/site/dev/design/pdftheory.md b/site/dev/design/pdftheory.md index a5521ba864..776adc16c5 100644 --- a/site/dev/design/pdftheory.md +++ b/site/dev/design/pdftheory.md @@ -62,7 +62,7 @@ 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 +therefore we can't calculate the table of contents until the size of objects is known, which requires assignment of object numbers. The document uses SkWStream::bytesWritten() to query the offsets of each object and build the cross-reference table. @@ -336,9 +336,9 @@ specified in the ContentEntry, similarly the Matrix and drawing state 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 +system before drawing these entities. We don't currently support inverted paths, so filling an inverted path will give the wrong result -([issue 241](https://bug.skia.org/241)). PDF doesn’t draw zero length +([issue 241](https://bug.skia.org/241)). PDF doesn't draw zero length lines that have butt of square caps, so that is emulated. ### <span id="Layers">Layers</span> ### @@ -367,7 +367,7 @@ 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 +* 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 @@ -408,7 +408,7 @@ subsetting support to Skia for TrueType fonts. 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 +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 @@ -452,8 +452,8 @@ 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 +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 @@ -464,11 +464,11 @@ 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 +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 +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 @@ -486,17 +486,17 @@ 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 +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 +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 +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 diff --git a/site/dev/sheriffing/index.md b/site/dev/sheriffing/index.md index 45be6201c1..dab6558246 100644 --- a/site/dev/sheriffing/index.md +++ b/site/dev/sheriffing/index.md @@ -143,7 +143,7 @@ If a Skia CL changes layout tests, but the new images look good, the tests need * First create a Chromium bug: * goto [crbug.com](https://crbug.com) - * Make sure you’re logged in with your Chromium credentials + * Make sure you're logged in with your Chromium credentials * Click “New Issue” * Summary: “Skia image rebaseline” * Description: diff --git a/site/user/sample/color.md b/site/user/sample/color.md index 3f4d869504..3283a98535 100644 --- a/site/user/sample/color.md +++ b/site/user/sample/color.md @@ -164,7 +164,7 @@ Opting In To Color Correct Skia ------------------------------- By itself, **adding a color space tag to a source will not change draw behavior**. In fact, -tagging sources with color spaces is always a best practice, regardless of whether we want Skia’s +tagging sources with color spaces is always a best practice, regardless of whether we want Skia's color correct behavior. Adding a color space tag to the **destination is the trigger that turns on Skia color correct |