| | <<<Back 1 day (to 2019/10/27) | Fwd 1 day (to 2019/10/29) >>> | 20191028 |
| Robin_Watts | kens, chrisl: Hey. | 10:50.36 |
| kens | Morning Robin_Watts | 10:50.43 |
| Robin_Watts | Morning | 10:50.45 |
| kens | Is the cluster unhappy ? | 10:50.54 |
| Robin_Watts | So, I know kens saw my burblings with Henry the other day. | 10:51.03 |
| | Is it? | 10:51.04 |
| kens | I'm guessing he office has no power, but it all seems stuck | 10:51.05 |
| Robin_Watts | Yeah, the office has no power, but that shouldn't have killed the other machines. | 10:51.28 |
| | Let me prod at it. | 10:51.31 |
| | Oh! | 10:57.49 |
| | I get it. | 10:57.51 |
| | mupdfmini is an android build job. | 10:58.01 |
| | not all the nodes are set up to do android builds. | 10:58.12 |
| kens | Yeah I wondere4d if it was that | 10:58.17 |
| Robin_Watts | In particular, no nodes outside the office are. | 10:58.19 |
| kens | But I didn't know enough | 10:58.24 |
| Robin_Watts | so if you schedule a job, you should be fine. | 10:58.26 |
| kens | It isn't affecting me, I'm coding halftones :-( | 10:58.41 |
| | How was terminator ? | 10:58.56 |
| Robin_Watts | Disappointing. | 10:59.03 |
| kens | Ah :-( | 10:59.07 |
| Robin_Watts | I mean, it's a watchable terminator film. | 10:59.13 |
| kens | Good for a plane then | 10:59.23 |
| Robin_Watts | But I had hopes that it'd move the story on much beyond T2, rather than just rehashing stuff. | 10:59.48 |
| | I rewatched Terminator on Friday, T2 on Saturday, T:DF on Saturday night, and T3 yesterday. | 11:00.14 |
| | I think T3 is actually a better film than Dark Fate. | 11:00.29 |
| kens | can't remember which is which after T2 | 11:00.44 |
| Robin_Watts | T3: Rise of the Machines | 11:00.59 |
| kens | So you missed out Salvation and Genisys apparently :-) | 11:01.41 |
| Robin_Watts | Well, I have both of those still to watch :) | 11:01.57 |
| | Anyway, to return to what I should be doing... | 11:02.15 |
| kens | From what I remember, I don't think I'd bother | 11:02.19 |
| | Yes, sure | 11:02.21 |
| Robin_Watts | I was burbling about 'preferred default resolutions' on friday. | 11:02.36 |
| kens | Yes, but I'm not convinced (as I said) that its particularly worthwhile | 11:03.00 |
| | Though I admit that ROPs is an argument in favour of 600 dpi | 11:03.13 |
| | except that we don't preserve those at all | 11:03.35 |
| chrisl | Default resolutions should be device dependent | 11:03.44 |
| Robin_Watts | The idea being that stuff like PCL would be "less bent" by going through pdfwrite at the default. | 11:03.52 |
| kens | WEll, I'm not really sure that's true | 11:04.09 |
| Robin_Watts | chrisl: This is specifically for high level devices, where the default resolution is more (but not entirely) arbitrary. | 11:04.15 |
| kens | As I said, we already do stuff lke spotting charpath+stroke, rectangular paths, ect | 11:04.31 |
| | and replace them with PDF equivalents | 11:04.42 |
| | And the argument about the co-ordinates being unchanged doens't really hold up after you;ve passed them through the CRM a couple of times | 11:05.10 |
| Robin_Watts | Does it not, really? | 11:05.21 |
| | cos the point of the exercise is to keep the CRM as being a simple power of 2, effectively. | 11:05.40 |
| kens | Well, I ran two files back to back a few days ago, one at 720 dpi, one at 72 dpi, because I was looking at teis problem | 11:05.44 |
| Robin_Watts | kens: yeah, 72 vs 720 is a bad example. | 11:06.05 |
| kens | The co-ordinates differed markedly, considering the input was the same in each case | 11:06.06 |
| Robin_Watts | cos that's a factor of 10, which doesn't fit nicely into floatingpoint. | 11:06.23 |
| kens | Well we need to end up in 1/72 space for PDF | 11:06.25 |
| Robin_Watts | whereas using 72*8 might work better. | 11:06.36 |
| kens | Possibly, I didn't try it | 11:06.47 |
| | But 600 dpi does not map neatly to PostScript/PDF units | 11:07.06 |
| | BTW I'm not saying that changing the resolution won't work, it demonstably will, I'm just highl;y doubtful about the benefits | 11:07.50 |
| Robin_Watts | 1800dpi would be a multiple of 72 and 600, but that's probably a tag high. | 11:09.09 |
| chrisl | What's the intended purpose of the change, anyway? | 11:09.18 |
| kens | If we render anything, then yes | 11:09.20 |
| | Henry was talking about "the output PDF should have the same units as the input" | 11:10.53 |
| Robin_Watts | chrisl: It was an idea raised by henry... let me find you his musins. | 11:10.55 |
| | musings. | 11:10.59 |
| | First off: | 11:11.17 |
| | We have discussed in the past using user coordinates in pdfwrite vs. | 11:11.21 |
| | device space coordinates. Well I don't know if it should be exactly | 11:11.22 |
| | called device space but there is a default resolution of 720 and the | 11:11.24 |
| | resolution can be set -r, etc. How is that related to this issue? | 11:11.25 |
| | Then in a subsequent mail: | 11:11.27 |
| | No I mean the output pdf should have the same units as the input. XL | 11:11.44 |
| | almost always starts out with 600 600 UnitsPerMeasure and gives | 11:11.46 |
| | coordinates in 1/600th of an inch. Today what happens with pdfwrite | 11:11.47 |
| | is the output units are in 1/720 of an inch by default. So a | 11:11.49 |
| | rectangle specified in pcl with width and height of 600 600 units | 11:11.50 |
| | would have a pdf rectangle with width and height of 720 units in the | 11:11.52 |
| | absence of the -r option, i.e. the pdf ctm would be .1 0 0 .1 0 0. | 11:11.53 |
| | PDF origin is at the lower left (PDF/PS) whereas PCL's origin is upper | 11:11.55 |
| | left. Ideally, we would like the input to have the same user | 11:11.56 |
| | coordinates as the output. With this set up we would never have an | 11:11.58 |
| | issue with odd multiples as we do now. | 11:11.59 |
| | Anyway I think this would be a major upheaval for pdfwrite, as I think | 11:12.01 |
| | about it, so I'll retract it :-) but that is what I meant. | 11:12.02 |
| kens | NB I have no recollection of such a discussion about "user co-ordinates" though that doesn't prove it didn't take place | 11:12.10 |
| | My feeling is that there is no great benefit in having the co-ordinate values in the PDF file have the same values as the co-ordinate values in the input | 11:12.44 |
| Robin_Watts | kens: I don't remember it either, but a) that doesn't really prove anything, given my memory, and b) maybe the discussions were over a decade ago. | 11:12.54 |
| kens | Yeah that's kind of what I meant, my memory is no better, so it could have happened and I fogot | 11:13.15 |
| chrisl | Using user coordinates isn't really supported by the architecture. It also would make life extremely unpleasant for anything *not* preserved as vectors | 11:13.31 |
| Robin_Watts | I don't know that I see a HUGE benefit in trying to keep the exact coords the same, personally. | 11:13.57 |
| kens | Well we'd end up with weird matrices being applied to map from (eg) 600 dpi to a nominal 72 (PDF units) | 11:14.20 |
| | And I don't really think the co-ordinates will be the same, similar, yes, but not the same | 11:14.44 |
| Robin_Watts | The thing that I thought might be desirable was the idea that we could avoid jitter in various conversions. | 11:14.48 |
| kens | And as I said, there's every chance that 4 l;ines forming a rectangle (for example) will be emitted asn an 're' whicih is utterly different | 11:15.13 |
| Robin_Watts | given we have code now that spots exact scales of bitmaps (a bitmap at 150dpi being displayed at 600dpi will go through the quadrupler and be a lot faster), it'd be nice if such bitmaps didn't end up being 4.0001 times larger. | 11:16.02 |
| kens | Why would we scale it ? | 11:16.40 |
| chrisl | The 720 dpi, AIUI, was chosen to best suit PS/PDF->PS/PDF conversions | 11:17.07 |
| Robin_Watts | chrisl: being a multiple of 72 makes absolute sense. | 11:17.26 |
| kens | Thing I mean is that we get the bitmap, and a scale factor, we write in the PDF the smae bitmap and the same scale factor | 11:17.28 |
| Robin_Watts | being a non-power of 2 multiple, less so. | 11:17.46 |
| | kens: Yes, but the scale factor will be calculated by compositing the different scale factors in the system. | 11:18.08 |
| chrisl | Robin_Watts: So, I'm not sure changing away from optimising for the two *by far* most used conversions, to benefit an extremely niche conversions makes much sense | 11:18.32 |
| kens | Yes, but we won't be scaling the bitmap, I don't think | 11:18.33 |
| Robin_Watts | so rather than getting '4' out, we're quite likely to get 4.0001 or something due to the vagaries of FP maths. | 11:18.40 |
| | chrisl: I'm not suggesting we do. | 11:18.46 |
| | kens: bitmap data will be unchanged. | 11:19.12 |
| chrisl | I thought you were proposing to change the default to 600 | 11:19.25 |
| Robin_Watts | but the scale factor may be altered a bit due to calculation errors. | 11:19.28 |
| kens | I think that even setting the resoltuion to 600 (or 300 or whtever) would result in thos kinds of rounding problems | 11:19.58 |
| Robin_Watts | chrisl: No. I've not got as far as describing my suggestion yet :) | 11:20.04 |
| kens | will shut up for now, and assign bugs | 11:20.21 |
| Robin_Watts | kens: possibly, but hopefully less so. It needs testing. | 11:20.23 |
| | chrisl: So, my suggestion was that each interpreter would have a 'preferred default resoluition'. | 11:20.41 |
| | which for PCL/PXL would be 600. Which for PS/PDF would be 72 or 720 or 576 or something to be decided. | 11:21.09 |
| chrisl | Which overrides the default of the device? | 11:21.24 |
| Robin_Watts | Then, when we run a job, if we're going to a high level device, and the resolution has not been explicitly set on the command line, or via PJL, we set the resolution to the preferred one before we 'init' the interpreter. | 11:22.14 |
| | (possibly we could have a dev_spec_op to do it, so that the device can overrule such preferred default settings?) | 11:23.31 |
| | chrisl: https://git.ghostscript.com/?p=user/robin/ghostpdl.git;a=commitdiff;h=d97049474baf31a2d8d269c63105d209a3dc054b | 11:23.53 |
| | That was what I hacked together on Friday in 90 mins or so. Compiles, but untested. | 11:24.14 |
| chrisl | I'm not keen on breaking the API like that, personally | 11:24.32 |
| Robin_Watts | Maybe this is a dead idea that we shouldn't pursue, but I wanted to get peoples thoughts. | 11:24.41 |
| | I'm not sure I see it as a "breakage" of the API. | 11:25.02 |
| kens | Well mostly I don't see this as having a lot of utility | 11:25.31 |
| Robin_Watts | ok. I'll not push it any further. We'll see how Henry feels about it when he appears, and we can drop it if he's not keen. | 11:26.39 |
| chrisl | I'm still not clear on the benefits: converting to PDF means converting to scalable format, so you can't rely on power of two optimisations in general, anyway. And if you're printing, either don't convert, or set the resolution for the printing device | 11:29.11 |
| | <<<Back 1 day (to 2019/10/27) | Forward 1 day (to 2019/10/29)>>> | |
Log of #ghostscript at irc.freenode.net.