Consider the following SVG:
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 40 20">
<g shape-rendering="crispEdges">
<rect x="0" y="0" width="20" height="20" fill="#b4b4b4"/>
<rect x="20" y="0" width="20" height="20" fill="#b4c4b4"/>
</g>
</svg>
The intended effect of the shape-rendering="crispEdges" annotation is to prevent there being a visible seam between the two rectangles, no matter how the rendering is scaled. This works as intended when viewing the SVG file in both Firefox and Chromium. However, when I convert the SVG into a PDF using inkscape -A and view the PDF, I can still see a visible seam at some zoom levels, e.g. as in this screen shot:
Moreover, the PDF page stream produced by inkscape is identical with and without shape-rendering="crispEdges"
1 0 0 -1 0 15 cm
q
0.705882 0.705882 0.705882 rg /a0 gs
0 0 15 15 re f
0.705882 0.768627 0.705882 rg 15 0 15 15 re f
Q
and the /ExtGState dictionary referenced as /a0 is also identical:
/ExtGState <<
/a0 <<
/CA 1
/ca 1
>>
>>
This could mean that there is no equivalent in PDF of this SVG feature, or it could mean that Inkscape's PDF exporter doesn't implement the equivalent. I'm not having any luck finding anything that sounds like this SVG feature in the PDF specification, which is an argument in favor of "no equivalent", but the PDF spec is gigantic and I could easily have missed something.
So the question is: Is or isn't there an equivalent in PDF of this SVG feature, and if there is, how do I use it? I am prepared to edit my exported PDF by hand if I have to.
Note 1: The example is minimal; I originally noticed the problem with a much more complicated figure from an academic paper, in which there are many such rectangles aligned to a grid, but some grid positions are empty. I tried enlarging the rectangles in the original figure so they would overlap, and I was not able to find an amount of enlargement that eliminated all visible seams without also visibly causing the rectangles to bleed into the empty spaces.
Note 2: With the original figure, the problem is visible with Evince, pdf.js, and two printers manufactured by different companies.
The closest thing in PDF would be to use shading meshes (e.g. tensor and lattice free form meshes). This will remove the slivers in most viewers.
Some PDF viewers ( like Acrobat, Xodo/PDFTron) have options that minimize the appearance of these slivers, but generally it's not well implemented across many implementations.
Related
I'm using the following extension method I built on top of itext7's com.itextpdf.layout.Document type to apply images to PDF documents in my application:
fun Document.writeImage(imageStream: InputStream, page: Int, x: Float, y: Float, width: Float, height: Float) {
val imageData = ImageDataFactory.create(imageStream.readBytes())
val image = Image(imageData)
val pageHeight = pdfDocument.getPage(page).pageSize.height
image.scaleAbsolute(width, height)
val lowerLeftX = x
val lowerLeftY = pageHeight - y - image.imageScaledHeight
image.setFixedPosition(page, lowerLeftX, lowerLeftY)
add(image)
}
Overall, this works -- but with one exception! I've encountered a subset of documents where the images are placed as if the document origin is rotated 90 degrees. Even though the content of the document is presented properly oriented underneath.
Here is a redacted copy of one of the PDFs I'm experiencing this issue with. I'm wondering if anyone would be able to tell me why itext7 is having difficulties writing to this document, and what I can do to fix it -- or alternatively, if it's a potential bug in the higher level functionality of com.itextpdf.layout in itext7?
Some Additional Notes
I'm aware that drawing on a PDF works via a series of instructions concatenated to the PDF. The code above works on other PDFs we've had issues with in the past, so com.itextpdf.layout.Document does appear to be normalizing the coordinate space prior to drawing. Thus, the issue I describe above seems to be going undetected by itext?
The rotation metadata in the PDF that itext7 reports from a "good" PDF without this issue seems to be the same as the rotation metadata in PDFs like the one I've linked above. This means I can't perform some kind of brute-force fix through detection.
I would love any solution to not require me to flatten the PDF through any form of broad operation.
I can talk only about the document you`ve shared.
It contains 4 pages.
/Rotate property of the first page is 0, for other pages is 270 (defines 90 rotation counterclockwise).
IText indeed tries to normalize the coordinate space for each page.
That`s why when you add an image to pages 2-4 of the document it is rotated on 270 (90 counterclockwise) degrees.
... Even though the content of the document is presented properly oriented underneath.
Content of pages 2-4 looks like
q
0 -612 792 0 0 612 cm
/Im0 Do
Q
This is an image with applied transformation.
0 -612 792 0 0 612 cm represents the composite transformation matrix.
From ISO 32000
A transformation matrix in PDF shall be specified by six numbers,
usually in the form of an array containing six elements. In its most
general form, this array is denoted [a b c d e f]; it can represent
any linear transformation from one coordinate system to another.
We can extract a rotation from that matrix.
How to decompose the matrix you can find there.
https://math.stackexchange.com/questions/237369/given-this-transformation-matrix-how-do-i-decompose-it-into-translation-rotati
The rotation is defined by the next matrix
0 -1
1 0
This is a rotation on -90 (270) degrees.
Important note: in this case positive angle means counterclockwise rotation.
ISO 32000
Rotations shall be produced by [rc rs -rs rc 0 0], where rc = cos(q)
and rs = sin(q) which has the effect of rotating the coordinate system
axes by an angle q counter clockwise.
So the image has been rotated on the same angle in the counter direction comparing to the page.
I create a SVG image with one rectangle. Attributes width & height units in mm:
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
width="210mm"
height="297mm"
version="1.1">
<rect
style="opacity:1;fill:none;stroke:#000000;stroke-opacity:1;stroke-width:0.5"
width="100mm"
height="100mm"
x="40mm"
y="60mm" />
</svg>
Then i convert that SVG with Inkscape and also with Apache Batiks SVG Rasterizer to PDF documents and print it on paper.
In both cases, a few millimeters are missing on the printed paper. The rectangle must be 100mm x 100mm, but it is accurate 97mm x 97mm. The larger the rectangle, the more millimeters missing.
To test my printer, i create a PDF with a PDF editor (Master PDF Editor) and a rectangle of 100mm x 100mm. In this printed PDF the rectangle is very accurate 100mm x 100mm.
How do you get the millimeter from the SVG without loss of size (or profit) on paper?
Thanks to RMo.
With Master PDF Editor is all ok, also the rectangle from SVG PDF.
Now i set in my PDF reader Okular (at print dialog) the margins to 0. Super, all is OK, the rectangle prints out with 100mm x 100mm.
Master PDF Editor has as default no margins or scalings.
In Gnome Evince, the scaling in the print dialog is set to 0 and everything is fine here as well. There are no margins.
We produce icons in Illustrator as SVGs and then produce font based icons with fontcustom. Out of no where, they were coming in too low. I found in the svg this odd viewBox with a negative 49 on it. How is this controlled in Illustrator? I don't want any viewbox, I just want a perfectly centered icon. I also see that it thinks that it is grouped. My only fix is to ungroup, and then set the X and Y to zero, and it works. It does put in a transform compensating to -49 on the layer. Something is causing this odd offset.
<svg version="1.1" id="Layer_1" xmlns:x="&ns_extend;" xmlns:i="&ns_ai;" xmlns:graph="&ns_graphs;"
xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" viewBox="-49 141 512 512"
style="enable-background:new -49 141 512 512;" xml:space="preserve">
Viewbox in illustrator is based on the art board I believe and it's a pain to get it to match the artwork exactly. The easy way to zero it all out is to just highlight the object in illustrator select copy.. then go to your code editor, make a new document and paste it. It will copy the svg code with a the view box set correctly(starting at 0,0). Then just save the file as an svg and you're done.
This question is related to
Script (or some other means) to convert RGB to CMYK in PDF?
however way more specific. Consider that I am not an expert in print production ;)
Situation: For printing I am only allowed to use two colors, Cyan and Black. The printery requests the final PDF to be in DeviceCMYK with only the Channels C and K used.
pdflatex automatically does that (with the xcolor package) for all fonts and drawn objects, however I have more than 100 sketches/figures in PDF format which are embedded in the manuscript. Due to an admittedly badly designed workflow (late realization that Inkscape cannot export CMYK PDFs), all these figures were created in Inkscape, and thus are RGB PDFs.
However, the only used colors within Inkscape were RGB complements of CMY(K), e.g. 100% Cyan is (0,255,255) RGB and 50% K is (127,127,127) etc.
Problem: I need to convert all these PDF figures from RGB to DeviceCMYK (or alternatively the whole PDF of the final manuscript) with a specific conversion formula.
I did a lot of google research and tried the often suggested ways of using e.g. Ghostscript or various print production tools in Adobe Acrobat, however all of the conversion techniques I found so far wanted to use ICC color profiles or used some other conversion strategy which filled the channels MY and spared some C and K, for example.
I know the exact conversion formula for the raw color numbers from our Inkscape-RGBs to the channels C and K, however I do not know or find any program or tool that allows me to manually specify conversion formulas.
Question: Is there any workflow to convert my PDFs from RGB to C(MY)K manually with my own specific conversion formula for the raw numbers with the converted PDF being in DeviceCMYK using a tool, script or Adobe product?
Due to the large number of figures I would prefer a batched solution which doesn't require too much coding from my side, but if it should be the only solution, I'd also be open minded for a workflow like "load/convert/save" within a program for every single figure or writing a small program with an easy-to-handle C++ PDF API for example.
Limitations and additional info: A different file format (like TikZ figures) is not possible any more since it does not work perfectly and the necessary adaptions to the figures would create too much overhead. A maybe helpful information: Since the figures are created in Inkscape, there are no raster images within the PDFs. I also do not want all figures to be converted to raster images during the color conversion.
Edit:
I have created an example of a RGB PDF-figure created with inkscape.
I also did a manual object-by-object color conversion to a CMYK-PDF with Illustrator, to show how the result should look like. Illustrator stores the axial shading in a DeviceN colorspace with the colors cyan and black, which is close enough^^
Here is an idea, I think it will work if your PDF files are using exclusively the colorspaces DeviceGray, DeviceRGB and DeviceCMYK:
1- Convert all your PDF files to Postscript (with pdf2ps from ghostscript for example)
2- Write a Postscript program that redefines the operators setrgbcolor, setgray and setcolor with your own implementation in the Postscript language, your implementation will internally use setcmykcolor and it will compute the values using your custom formula.
Here is an example for redefining the setgray operator:
% The operator setcmykcolor expects 4 values in the stack
% When setgray is called, we can expect to have 1 value in the stack, we will
% use it for the black component of cmyk by adding 3 zeros and rolling the
% top 4 elements of the stack 3 times
/setgray { 0 0 0 4 3 roll setcmykcolor } bind def
3- Paste your Postcript program at the begining of each resulting ps file from step 1.
4- Convert all your files back to PDF (with ps2pdf for example)
See it in action by saving this piece of code as sample.ps:
/setgray { 0 0 0 4 3 roll setcmykcolor } bind def
0.5 setgray
0 0 moveto
600 600 lineto
stroke
showpage
Convert it to PDF with ghostscript using this command line (I used version 9.14):
gswin64c.exe -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=sample.pdf sample.ps
The resulting PDF will have the following page content:
q 0.1 0 0 0.1 0 0 cm
/R7 gs
10 w
% The K operator is the PDF equivalent of setcmykcolor in postscript
0 0 0 0.5 K
0 0 m
3000 3000 l
S
Q
As you can see, the ps-> pdf conversion will preserve the cmky colors specified in postscript with the setcmykcolor operator.
Maybe you can post your formula as a new question and someone could help you out translating it to postscript.
Since you have access to Illustrator, you might want to try importing the PDF into Illustrator and using Illustrator's scripting capabilities to iterate over the elements and replace fill/stroke RGB colors with their CMYK replacement colors.
The difficulty will be with the shading patterns (Gradients) used in the PDF; if they are imported as GradientColor, then in theory it's a matter of digging into the GradientColor to find the base RGB colors and substitute their CMYK replacement.
A very similar problem was solved using the ActivePDF.dll with C++ (or C#??).
I'm working on a Win8 editor which is basically based on a Canvas and Shapes like Line, Rectangle, etc. on it. Those shapes can be manipulated by the user. Now I want to implement a custom shape that take a list of 2D points from a laser scan (used in architecture).
So my question is, which base primitive would you use to display lets say 500 points? I was thinking of a Path but then I get rather a set of connected lines (path, polygone) instead of just the dots. So what else?
This picture illustrates what I want to achieve. All blue dots should be in one shape that can be dragged by the user.
My first guess would be the PathGeometry filled with a lot of RectangleGeometries or EllipseGeometries. But I wonder what this means in terms of performance.
<Path Fill="LemonChiffon" Stroke="Black" StrokeThickness="1">
<Path.Data>
<RectangleGeometry Rect="50,50,5,5" />
<RectangleGeometry Rect="60,50,5,5" />
<RectangleGeometry Rect="70,50,5,5" />
...
</Path.Data>
</Path>