Timeline for How does PDF export handle text alignment?
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 13, 2018 at 5:38 | comment | added | Jason Gross | Thanks, but the box-around-each-character is actually just a contrived example for pushing on the bit I didn't understand (that rasterize / image dimensions gets more and more off from pdf export as the length of the string grows); my actual issue that I'm solving is mathematica.stackexchange.com/questions/162942/… | |
| Jan 13, 2018 at 2:07 | comment | added | Alexey Popkov | If you wish to add a frame around each character, it is possible to achieve with Grid: Grid[{Characters["aaaaaaaaaaaaaaaaa"]},Spacings->0,Frame->All,FrameStyle->AbsoluteThickness[0.01]]. But this approach will destroy the inter-character spacing in non-monospaced fonts (which is already wrong even for monospaced fonts, so it isn't a big deal). | |
| Jan 12, 2018 at 18:54 | comment | added | Alexey Popkov | ImageCrop uses Rasterize under the hood, it can't be avoided. Export to PostScript formats (PDF, EPS) seems to use it's own conversion rules which are independent from Rasterize. "Certainly, it should not accumulate as I add more characters." - Yes, the more identical characters, the lesser should be error. | |
| Jan 12, 2018 at 18:43 | comment | added | Jason Gross | @AlexeyPopkov In any case, because I am aligning each box based on the raster size of the entire string up to that point, being consistently off by 1-2 pixels on an entire object shouldn't impact much of anything. Certainly, it should not accumulate as I add more characters. That is, if I have n "a"s followed by a "b", and I render that, and then I offset a box by the width of n "a"s, it seems odd that things would line up perfectly in the display in Mathematica, but be off in the pdf export by an amount that grows with n. (Though I guess monospaced fonts not being monospaced might do) | |
| Jan 12, 2018 at 18:41 | comment | added | Jason Gross | @AlexeyPopkov Replacing Rasterize[..., "RasterSize"] with ImageDimensions[ImageCrop[Graphics[...]]] shows a very similar issue; does ImageDiminsions have the same problem? | |
| Jan 12, 2018 at 18:36 | comment | added | Jason Gross | @Themis it shows up when I use pdf2png.com to convert the pdf to a png, and inspect the pixels of the png, so I don't think it's a screen rendering issue. | |
| Jan 12, 2018 at 18:36 | history | edited | Jason Gross | CC BY-SA 3.0 | Fix a typo |
| Jan 12, 2018 at 17:50 | history | edited | Alexey Popkov | CC BY-SA 3.0 | added 2 characters in body; edited tags |
| Jan 12, 2018 at 17:43 | comment | added | Alexey Popkov | You shouldn't trust Rasterize in determining the size of anything, especially when it is a text string. Rasterize is known to be off by 1-2 pixels even in situations when it deals with exact objects. The case of textual primitives is especially painful. | |
| Jan 12, 2018 at 17:16 | comment | added | Alexey Popkov | Tangentially relevant: "Monospaced fonts are not monospaced." Mathematica has serious problems with character positioning both in the FrontEnd and in Export, unfortunately. | |
| Jan 12, 2018 at 14:57 | comment | added | Themis | I don't see the misalignment on MacBook Pro with 11.1.1. Do you still have a problem if you print? It might be a screen rendering issue. | |
| Jan 12, 2018 at 10:58 | history | edited | Jason Gross | CC BY-SA 3.0 | Add explicit question |
| Jan 12, 2018 at 10:44 | history | asked | Jason Gross | CC BY-SA 3.0 |