| | <<<Back 1 day (to 2022/07/26) | Fwd 1 day (to 2022/07/28) >>> | 20220727 |
| artifexirc-bot | <chrisl> tbrowder: gs (as we ship it, anyway) doesn't include any networking functionality, so it's hard to see how a firewall could affect it | 06:40.34 |
| | <chrisl> The information from a release binary will be limited, but you could open the dumped core in gdb, and it might give you an idea of where the problem occurred. | 06:42.42 |
| | <velix> @KenSharp According to 705684: How did you change the pattern types? | 08:01.10 |
| | <KenSharp> I edited the file | 08:01.22 |
| | <KenSharp> The file I attached to the bug report (I did attach the file, didn't I ?) was hand edited | 08:01.40 |
| | <velix> You did, yeah. Okay, I thought you changed something on PDF level. | 08:01.57 |
| | <KenSharp> But it's not the PatternType, its the TilingType | 08:02.02 |
| | <velix> Sorry. | 08:02.06 |
| | <KenSharp> All I did was change all instances of TilingType 3 to TilingType 2 | 08:02.26 |
| | <velix> Okay. Ah okay. | 08:03.07 |
| | <KenSharp> It is possible the pattern cell is incorrect, but TilingType 3 does allow for 'extra' distortion (without saying what exactly). so on the face of it, what we are doing (sacrificing accuracy for performance) is permitted. | 08:04.09 |
| | <KenSharp> Of course, no PDF consumer **has** to do this, it is entirely up to the application. | 08:04.34 |
| | <KenSharp> We have discussed in the past adding (yet another!) Ghostscript option to force TilingType to be treated as 2, because this isn't the first time someone has reported this as a bug | 08:05.15 |
| | <velix> @KenSharp Indeed the file looks fine now. Do you think that replacing TilingType3 with 2 is fine for this kind of artwork? | 08:15.10 |
| | <KenSharp> Well, TilingType 2 can introduce an error in placement of the cell of up to 1 device pixel, which I know can be important for you. On the other hand, it is the cell placement, not the feature placement. It seems to me that if the cell phase is also important that the error of 1 device pixel is the smallest error, but its really up to you to judge that I think, I'm not qualified | 08:16.26 |
| | <velix> @KenSharp Okay, I'll do some testing. I'm currently developing a workflow, how to repload the TilingType. Then I can test it. | 08:19.30 |
| | <KenSharp> I'll talk with @chrisl again about whether we should introduce a --force-tilingtype or something to allow people to override the pattern defined TilingType, as I said it has come up before, it's just a general reluctance to add yet more options to GS. | 08:31.50 |
| | <chrisl> I'm still a bit reluctant, as far as I can tell, what we're doing is perfectly legal, and adding yet another command line option isn't going to stop the reports and having to explain it | 08:34.59 |
| | <KenSharp> Certainly true on both counts | 08:35.18 |
| | <velix> Nah... you don't need to do that for me. I've unpacked the PDF using mutool and sed TilingType 3 to 2 ;) | 08:43.33 |
| | <velix> now maaany tests are running | 08:43.50 |
| | <KenSharp> I have a feeling that the original file is uncompressed enough that you can do that directly in the file. I could be wrong | 08:44.04 |
| | <velix> @KenSharp I don't know if Illustrator produces the same result all the time. | 08:45.05 |
| | <velix> maybe on next upgrade, I'll be doomed ;) | 08:45.14 |
| | <velix> processing takes ~ 10 seconds. so no problem. | 08:45.32 |
| | <KenSharp> Well uncompressing it will work of course, at the expense of a lrager (maybe much larger) output file. The only way that Illustrator would be able to defeat that would be to use a compressed object stream (ObjStm) which is fairly unusual. Partly because it usually doesn't gain you much. | 08:46.18 |
| | <chrisl> Could be Illustrator just chooses not to take advantage of the optimisation allowed by the spec. It is *allowed* but not required..... | 08:47.06 |
| | <velix> @KenSharp I'm doing mutool clean -gggg -c -s -z afterwards ;) | 08:47.27 |
| | <velix> Okay, seems like png16malpha needs -dTextAlphaBits=4 -dGraphicsAlphaBits=4, which pngalpha doesn't. Does it get double-anti-aliasing when using -dDownScaleFactor? | 11:33.19 |
| | <chrisl> The whole point of png16malpha is that it doesn't automatically enable anti-aliasing | 11:34.33 |
| | <chrisl> It's meant to be used with DownscaleFactor rather than *AlphaBits | 11:35.23 |
| | <chrisl> Or no anti-aliasing at all | 11:36.59 |
| | <chrisl> (Heading out for an hour or so....) | 11:37.18 |
| | <velix> @chrisl Ah okay. Thanks. Compared to output of Illustrator, Photoshop & mutool, the output of png16malpha looks a little "thicker" on every stroke. I thought "double" anti-aliasing might be the reason for this. | 11:39.35 |
| | <tbrowder> chrisl: thanks | 12:03.10 |
| | <<<Back 1 day (to 2022/07/26) | Forward 1 day (to 2022/07/28)>>> | |
Log of #ghostscript at irc.freenode.net.