| | <<<Back 1 day (to 2011/11/03) | 2011/11/04 |
| henrys | alexcher:if a problem stopped you from checking in a commit - you said it did - it should be reported as a bug. | 01:39.54 |
| arthurf | tor8: there is some improvement in the zoom - there are some remaining issues which I'm sure you're seeing. | 02:13.33 |
| | I like how MuPDF on iOS remembers where one left off on a particular PDF. | 02:19.28 |
| mvrhel | henrys: so it would be nice to get the file for 692611 | 04:40.12 |
| | good night | 05:21.00 |
| arthurf | tor8: Please check out 692660 - this may be a fix for the zoom problem I noticed with the latest build, commit 83621651795dda31a3a10a02e1072bf976d108bc. | 06:08.10 |
| kens | chrisl I see GG has published 3rd quarter results | 08:04.30 |
| | I was tickled by: | 08:05.11 |
| | "We are also delighted to say that our PDF creation library is gaining traction: it has been verified as being faster, producing higher-quality conversions and with a smaller footprint than Adobe® Acrobat® when converting documents into PDF from Microsoft Office" | 08:05.11 |
| chrisl | So, still milking the cash cow, then! | 08:10.29 |
| kens | I assume that's what he's saying, yes :-) | 08:10.43 |
| | One wonders just how bad the results would be otherwise. | 08:11.10 |
| chrisl | I like the "gaining traction", too, that'll be the traction it lost because nobody cared for so long....... | 08:11.54 |
| kens | I'm surprised its gaining anything, to be honest | 08:12.11 |
| | I'd have thought that everyojne who wanted one already had one, or used a cheapie knock-off | 08:12.27 |
| | BTW my JBIG2 spec is the *draf* copy, but I'm pretty sure its essentially the same for our purposes as the released version (unlike JPEG2000) | 08:13.22 |
| chrisl | I suspect there are still corporate buyers and OEMs who want better than a freebie, but cheaper than Adobe - I mean, we make sales in there. | 08:13.30 |
| kens | True. | 08:13.38 |
| | Amazing that its still doing well... | 08:13.50 |
| chrisl | Also, I strongly suspect this is not going to be growth compared to 5-6 years ago, it's probably cloying back some of that business that leaked away since then | 08:14.33 |
| kens | I guess that's true. The results don't look good ot me, continuning to make losses even after cost reductions, sales down again etc. | 08:15.15 |
| | Great, Tim Waugh has supplied the example file as a .XZ compressed archive. | 08:18.12 |
| | And the file is a 3MB compressed PS file! | 08:21.59 |
| chrisl | I saw that. I was thinking about punting it back and saying "use compression with wider platform support"..... | 08:24.06 |
| kens | I will make such a comment later. | 08:24.22 |
| | Although XZ *is* available for Windows now | 08:24.31 |
| | But its still not a widely used format. ANd it only saved 25% | 08:24.46 |
| | Werid, its a 4Mb file that draws two staves of music | 08:25.27 |
| chrisl | Well, a big chunk of it is image, or everything is drawn as explicit vectors (rather than using a font). There is a package out there that does that. | 08:26.53 |
| kens | Ah, and some Korean text underneath. Presumably the file includes a complete font.... | 08:27.03 |
| chrisl | And that's the one that crashes? | 08:27.36 |
| kens | Alleegedly, I'm just rying his ocmmand line | 08:27.54 |
| | Indeed, it does crash | 08:28.24 |
| | Quite quickly | 08:28.28 |
| | Looks like its trying to write out the font, which is not a great surprise. | 08:29.03 |
| kens | unlimbers debugger | 08:29.18 |
| | Well, it appears to have run off the end of the font while interpreting a CharString | 08:31.07 |
| | For a SEAC or similar | 08:31.33 |
| | And it does look like the font contains way more glyphs than needed | 08:32.58 |
| | So it probably works normally because the offending glyph isn't actually used. | 08:33.15 |
| chrisl | That could be nasty to solve..... | 08:35.06 |
| kens | It may not *be* solvable | 08:35.21 |
| | It may be that the CharString is corrupt | 08:35.30 |
| chrisl | One would hope it would be possible to stop it crashing. | 08:36.00 |
| kens | Maybe, how do you know when you've run out of CharString data ? | 08:36.20 |
| | I don't see a length anywhere here.... | 08:36.29 |
| | But this is early days. | 08:36.36 |
| chrisl | It's a string, there should be a length in the string object...... | 08:36.51 |
| kens | Nope, its not a string in the C code. | 08:37.05 |
| | Its a const byte * | 08:37.17 |
| | OK I do have a size. | 08:37.59 |
| | So I can definitely return an error | 08:38.16 |
| | At a performance cost of checking the pointer after every operation | 08:38.46 |
| chrisl | I think that's how the GS T1 charstring code works, and it's definitely how the FT code works. | 08:40.12 |
| kens | This is (more or less) the GS type 1 parser. | 08:40.26 |
| | Its one of the (three ?) type 1 parsers in the pdfwrite code. | 08:40.40 |
| | Well actually in the font code generally. This is in gxtype1.c | 08:41.02 |
| | The code claims all it does is return the two character codes for a SEAC. | 08:41.51 |
| | Being a Korean font, the glyoh is quite large and complex. | 08:42.21 |
| | OK going to extract and decode the font, this is too tedious. | 08:46.03 |
| chrisl | Hmm, yes, it's the standalone charstring decryption that checks limits. | 08:46.56 |
| kens | Which doesn't get used here. Also I think it may be a subr which is at fault | 08:47.20 |
| | <sigh> And of course the file contains multiple fonts.... | 08:47.46 |
| chrisl | You want it to be easy? ;-) | 08:48.09 |
| kens | It would be nice.... | 08:48.17 |
| chrisl | Well, you could always punt it back. | 08:48.35 |
| kens | Tim (or whoever reported it to him) could have made a simpler file | 08:48.39 |
| | Looks like there are only 2, so I can extract the one I *think* is going wrong. | 08:49.30 |
| | Which does indeed appear to be the Korean font (not even subset!) | 08:50.19 |
| chrisl | Which means we can't blame the subsetter for the breakage! | 08:50.48 |
| kens | I suppose. Actually this is a CFF font. | 08:52.34 |
| | :-) The font crashes cffdisasm as well..... | 08:55.22 |
| chrisl | I haven't found that to be a terribly rare event. I don't think I've ever found a CFF CID font that cffdisasm worked on | 09:05.35 |
| kens | It should, I've used it lots. | 09:12.33 |
| | Of course, I wrote it ;-) | 09:12.59 |
| chrisl | Well, of course, the only reason I would want to disassemble a font is if I thought there was a problem with it! Although, I suspected there was an issue with fonts with *lots* of glyphs in them - never had the chance to investigate. | 09:14.05 |
| kens | I've always developed it by waiting until I had a font that broke it, and then figuring out why.... | 09:14.34 |
| | Most of this font works fine, but it does crash in a CharSting, and some of the subr indices look very unlikely (eg subr -1036) | 09:15.22 |
| chrisl | Ah, these hyperspace subrs are a complicated feature...... | 09:15.56 |
| kens | OK its crashing because its indexing into a tabl;e of escaped names wiht an index > size of the table. | 09:16.16 |
| | I'll add a guard for that condition. | 09:17.13 |
| | Well, that completes OK now, including dumping the FDArray | 09:20.20 |
| | Hmm, this doesn't look right: | 09:22.02 |
| | Index: Gsubr 1917 | 09:22.02 |
| | { | 09:22.02 |
| | 3 -1093 callgsubr | 09:22.02 |
| | return | 09:22.02 |
| | } | 09:22.03 |
| chrisl | I wonder if other interpreters abs() the value before trying to call it | 09:23.19 |
| kens | I think the offsets may be wrong ebfore that, so its dumping garbage | 09:23.40 |
| | Though its hard to say for sure, the strings look OK. | 09:24.14 |
| | ANd that's the index immediatley befopre the Gsubrs | 09:24.25 |
| | FWIW this is apparently an *Adobe* font. | 09:24.55 |
| chrisl | Well, we may not be able to blame the subsetting, but it's far from unheard-of that the embedding actually broke the font | 09:25.51 |
| kens | I'm not prepared to blame anyone but us yet.... | 09:26.21 |
| | But I am going to have to decode the font which is going to be slow and painful. | 09:26.37 |
| | Well, the Gsubr call is definitely supposed to be negative. What the heck does that eman ? | 09:46.21 |
| | Oh, its the bias. | 09:47.35 |
| | So I need to add 1131 to the GSUBR index | 09:47.57 |
| | So its actually 38.... | 09:48.12 |
| | Ah. All the places where I get invalid codes are immediately preceded by a hintmask. I suspect the hint counting is incorrect. | 10:09.02 |
| | COuld be a problem with cntrmask too | 10:09.18 |
| | Hmm, I wonder how you are supposed to know how many hints are present in a GSUBR.. I guess you aren't supposed to know. | 10:10.28 |
| JimPansen | hi | 10:10.48 |
| ghostbot | privet | 10:10.48 |
| chrisl | kens: it's a *long* time since I looked at that area :-( | 10:11.11 |
| kens | chrisl the hintmask is *followed* by a variable number of bytes determining the mask values. The number of bytes is determined by the number of hints. So in a subroutine, how can I tell how many hints are going to be in force when the subr is called ? :-( | 10:12.10 |
| | Its a really stupid design decision. | 10:12.22 |
| JimPansen | what might be the reason for gs not doing path optimization (gx_path_type_optimize) when converting pdfs? | 10:12.39 |
| kens | Why do you think it should ? | 10:12.59 |
| JimPansen | because the code suggests it can ;) | 10:13.29 |
| kens | But there's no reason why it should, just because it can.... | 10:13.52 |
| | ANyway, that's only called by high level devices. | 10:14.13 |
| JimPansen | and the original pdf draws millions of rectangles of size 1x1 ... | 10:14.14 |
| chrisl | There's a good reason it shouldn't - it might get in the way of the output accurately representing the input....... | 10:14.50 |
| kens | Which is why its only done for high level devices | 10:15.04 |
| JimPansen | k... let's just assume i'd _like_ it to do such optimization ;) | 10:15.36 |
| kens | What device are you using ? | 10:15.46 |
| JimPansen | pdfwrite(?) | 10:15.59 |
| kens | Well pdfwrite will use it where it can. | 10:16.07 |
| | See gdevpdf.c and gdevpdfd.c | 10:16.15 |
| | Lots of filled rectangles are not a subject for optimisation | 10:16.29 |
| | Optimisation refers to optimising a single path, not a sequemce of paths | 10:16.58 |
| | The optimisation is done in gdevvec.c | 10:18.16 |
| | If you want to see what it actually does. | 10:18.25 |
| JimPansen | kens: hmm... know of any tools that can merge such 1x1 rectangles? businesspartner is claiming he optimized a sample PDF, and looking at the pdf operators it seems like thousands of "x y 1 1 re f" lines were merged into a few "x y w h re f*" lines... | 10:34.54 |
| | and he claims this was done by gs... | 10:35.12 |
| kens | I don't know how he would have done that, I can't think of any way. | 10:35.36 |
| | The colours of the rectangles would have to be the same for starters, and if that's the case then teh PDF was spectacularly baldy created in teh first place. | 10:36.25 |
| | Can we see an example ? | 10:36.31 |
| JimPansen | perhaps some commercial tool he "forgot" about? | 10:36.38 |
| kens | Possibly, but it seems unlikely. Not impossible, but.... | 10:36.55 |
| JimPansen | kens: absolutely @ badly created xD | 10:37.11 |
| kens | Its a lot of work to undo saomethign which shouldn't have been done in the fist place, so I can't see why someone would write a tool to do it. | 10:37.19 |
| | Unless these are common files. | 10:37.25 |
| Robin_Watts | Sounds like something has converted images to pixel sized rectangles to me. | 10:37.58 |
| kens | Agreed. I though it might have been pswrite, then the PS converted back to PDF. | 10:38.25 |
| | But that's such a convoluted route..... | 10:38.34 |
| JimPansen | kens: colors are the same for the pixels... | 10:38.44 |
| | i tried pdf -> ps -> pdf, but that didn't help | 10:39.05 |
| kens | It won't, once teh damage is done, GS will honour what it sees in the file. | 10:39.24 |
| | Where did the PDF file come from ? | 10:39.36 |
| JimPansen | not sure. it's an ad, probably sent in by the customer himself | 10:41.29 |
| | ist has set "Normalizer demonorm" as its producer | 10:41.44 |
| kens | So we don't know the workflow at all. Probably it has been through several conversions already which is where the problem arises. | 10:41.55 |
| | Never heard of that producer.... | 10:42.07 |
| | Ah, its an implementation of Adobe's 'Normalizer' | 10:42.40 |
| | WHich converts PostScritp to PDF (ie Distiller but as a SDK) | 10:43.18 |
| | So its the original PostScript which is crappy. I would guess that the file started life as a PDF, was converted to PostScript using GS's old pswrite device which converted an image to loads of filled rectangles. Then the PostyScript was converted back to PDF | 10:44.07 |
| | Why anyone would do that escapes me but it looks like that. I don't believe Normalizer did the conversion ot filled rectangles. Does the PDF have any other metadata ? | 10:44.51 |
| JimPansen | Creator(PDFL 8.0) | 10:45.49 |
| kens | Hmm, off to Google again.... | 10:46.00 |
| JimPansen | and title is "PSAdjustIsNormalized" | 10:46.18 |
| kens | Looks like PDFL is the Adobe PDF Library | 10:46.49 |
| | So possibly its the original application at fault. | 10:47.10 |
| | Anyway, its pretty irrelevant, I can't think of a way to do what you want, because GS/pdfwrite just isn't set up to do that. We probably could write such an optimisation, so if you want to open an enhancement bug go ahead, but it won't be done soon, if ever. | 10:47.59 |
| JimPansen | then the question is, where did he get the "optimized" version from? could be from somewhere in the workflow, before the crappy code was introduced... | 10:48.20 |
| kens | That would seem likely to me. I don't know of anything which is likely to undo that because its such an unlikely thing to do. | 10:48.51 |
| JimPansen | xD | 10:49.01 |
| kens | I freely admit that the old pswrite device for GS does exactly that, but we have deprecated that. | 10:49.16 |
| JimPansen | when, approximately, whas is deprecated/fixed? | 10:51.10 |
| kens | It was deprecated in the last release, its not been 'fixed' because its not 'broken', its just sub-optimal | 10:51.36 |
| | Anyone using the supplied scripts up to version 9.02 would have got pswrite if they converted to PostScript, because the scripts all used that. | 10:52.16 |
| | I altered ps2write so that it emitted DSC-compliant PostScript in 9.04, so we deprecated the old pswrite device, and changed the scripts to use ps2write. | 10:53.01 |
| | You can still use pswrite, its srtill built in, but you would have to explicitly command it. Its still there in case anyone should want to do level 1 PostScript output (in which case they should be taken out and put out of their misery) | 10:53.57 |
| JimPansen | oh... so one would have to use the very latest versions to be on the safe side with ps(2)write? | 10:54.31 |
| kens | Yes. Or not use the ..2ps scripts, but explcitly use the ps2write device on a GS command line | 10:55.02 |
| JimPansen | good to know | 10:55.30 |
| | so in what circumstances would the old pswrite create single-pixel rects? | 10:56.26 |
| kens | When an image cannot be represented in level 1 PostScript | 10:57.01 |
| JimPansen | color gradients? | 10:57.18 |
| kens | Don't understand. images don't care about the content | 10:57.43 |
| | Masked images are one example | 10:58.02 |
| JimPansen | oh, raster images then | 10:58.20 |
| kens | images are always raster. | 10:58.31 |
| | THat's what image meanss in PostScript and PDF | 10:58.38 |
| JimPansen | i see | 10:59.03 |
| | well, thank you very much | 11:00.02 |
| kens | However shading dictionaries would have to be converted to images and its possible that pswrite isn't smart enough to emit those as an image. I don't recall off-hand, and we really don't care about pswrite any more.... | 11:00.04 |
| | Haven't done for some time in fact. | 11:00.14 |
| JimPansen | i won't bug you any further, now. thanks for taking the time :) | 11:03.19 |
| kens | No problem. | 11:03.25 |
| Robin_Watts | tor8: Looks like arthurf may have found the iOS zooming thing for you. | 11:44.15 |
| tor8 | Robin_Watts: it's worse than that, zooming fails completely on pages with non-zero /Rotate | 11:44.46 |
| | I was too tired to fix it properly yesterday before committing | 11:44.58 |
| Robin_Watts | oh... That's iOS only? | 11:45.30 |
| tor8 | yeah. my zooming calculates the wrong offset for the tile because it doesn't take the MediaBox lower edge offsets and /Rotate into account | 11:46.01 |
| | at least that's the problem that the bug report in bugzilla mentions :) | 11:46.43 |
| | the image zooming thing, I'll have to look into more depth later unless you want to have a go? | 11:46.59 |
| | I can probably make some example screenshots to illustrate the issue | 11:47.08 |
| Robin_Watts | I have something to occupy me today. | 11:47.22 |
| | but presumably it should occur on android and the desktop too? | 11:47.49 |
| tor8 | it looks like we're off by one "texel" when filling the image contents | 11:47.54 |
| | yeah | 11:47.57 |
| Robin_Watts | So it's zooming in that's wrong (i.e. scaling up?) | 11:48.37 |
| | That would explain why disabling the scaling code makes no difference :) | 11:49.11 |
| tor8 | Robin_Watts: well, I think it's drawing images wrong always, regardless of scaling | 11:53.42 |
| | but it seems to be aggravated by zooming in | 11:54.05 |
| | I only noticed it because the images kept shifting when I changed zoom levels | 11:54.18 |
| | because I have the lower res page image as a backdrop until it renders at the new zoom level | 11:54.45 |
| | but that backdrop is drawn and scaled by iOS | 11:55.01 |
| | the text and vector graphics behave as expected, but the insides (not edges) of images seem to shift around. how much depends on the image resolution. | 11:55.34 |
| Robin_Watts | tor8: a question about xps patterns. | 12:33.23 |
| | PS and PDF recognise that sometimes patterns can't safely be repeated at regular device space intervals, and so they have different painttypes to allow the author of the file to specify if the pattern repeats at an exact multiple of the device resolution, or whether the pattern gets 'bent' to fit. | 12:34.46 |
| | Does xps have the same ? | 12:34.52 |
| tor8 | *goes looking in the spec* | 12:35.32 |
| Robin_Watts | downloads the spec at the moment. | 12:36.50 |
| JimPansen | now that's interesting... pdfwrite also creates 1x1 rectangles. how much depends on the -r parameter, which is 720 by default... | 12:36.54 |
| tor8 | ECMA-388.pdf is the one I'm reading | 12:36.59 |
| | Robin_Watts: one simplification XPS has, there isn't the same madness with the pattern transform matrix that ps/pdf has | 12:37.45 |
| Robin_Watts | Ah, maybe that answers my question :) | 12:38.29 |
| tor8 | they don't have the option that PDF has about being strict or relaxed about tile spacing either | 12:38.59 |
| | checking if there's anything in the "rendering rules" section | 12:39.26 |
| | Consumers MUST precisely position the tiles specified by the image brush and visual brush. If the specified values result in fractional device pixels, the consumer MUST calculate a running placement-error delta and adjust the placement of the next tile where the delta reaches a full device pixel in order to keep the tiles from being increasingly out of phase as the expanse of the path is filled [M11.9]. | 12:39.48 |
| | section 18.7.3 | 12:39.57 |
| | Consumers MAY choose any technique desired to achieve this requirement, such as linear filtering for seams, stretching of the tile (up-sampling or down- sampling), or pre-computing multiple tiles and adjusting behavior according to how the tiles fit on a grid [O11.23]. | 12:40.31 |
| | so placement must be accurate, rendering needn't be :) | 12:40.43 |
| Robin_Watts | Thanks. | 12:40.44 |
| | gxps uses a tiling type of 1. | 13:12.55 |
| | Which is: "Constant spacing: Pattern cells are spaced consistently - that is, by a multiple of a device pixel." | 13:13.32 |
| | Which seems precisely wrong according to the spec. | 13:13.43 |
| | TilingType 2 would seem more approprirate. | 13:13.57 |
| | "No distortion: The pattern cell is not distorted, but the spacing between pattern cells may vary by as much as one device pixel in both x and y dimentions when the pattern is painted." | 13:14.32 |
| tor8 | yes, that sounds about right | 13:15.36 |
| kens | Well, no sign of 'Pogressive Casulty Insurance' in our customer list. Of course the fact that he's made two spelling errors in the name of the company he works for doesn't inspire confidence..... | 13:18.33 |
| Robin_Watts | Damn, and after I'd just fixed the bug by tweaking the TilingType1 code :) | 13:18.41 |
| tor8 | Robin_Watts: the image rendering is wonky when doing the bilinear filtering... if I always do nearest neighbor it works as expected! | 13:18.42 |
| Robin_Watts | tor8: Ah! | 13:18.53 |
| | Well, that's good news. | 13:19.00 |
| tor8 | which explains why I only see it when zooming in :) | 13:19.15 |
| | yeah, narrows down the search space quite a lot! | 13:19.25 |
| | argh, not quite, there's still something else shifting now :( | 13:20.57 |
| Robin_Watts | Obvious suggestion of the day; fix the non-filtered version, then worry about the filtered version later. | 13:23.56 |
| tor8 | yeah. something's off about the texture matrix we're computing | 13:30.25 |
| | I think it's getting the image height scaling off by one or something like that | 13:30.53 |
| Robin_Watts | Hurrah. Looks like I have another commit that's going to change 1000s of images very slightly. | 13:34.23 |
| kens | :-( | 13:38.04 |
| | Only for XPS ? | 13:38.15 |
| | Bizarre. If I open a 20Mb file with Wordpad (plain text) then the Wordpad executable eats 100Mb of memory..... | 13:39.51 |
| chrisl | It probably converts it to wchars for display | 13:40.36 |
| kens | Even so, a factor of 5 ? | 13:40.52 |
| chrisl | Well, I think wchars are four bytes, so..... | 13:41.13 |
| kens | the other 20% ? | 13:41.30 |
| chrisl | The original ASCII? | 13:41.44 |
| kens | Oh god, its possible given MS.... | 13:41.57 |
| chrisl | That's how notepad used to work | 13:42.18 |
| kens | VS loads it into about 50Mb. | 13:42.29 |
| | ANd it scrolls much faster | 13:42.38 |
| | 10 subrs which contain hin/cntrmasks operators. | 13:43.10 |
| | And a bunch of routines which have no hints, but call gsubrs which supply the hints :-( | 13:43.26 |
| | So the only way to deal with those is to actually run the subrs. | 13:43.40 |
| chrisl | Meanwhile, Type 1 font with PS procedures instead of CharStrings - of all the stupid things........ | 13:44.06 |
| kens | Ah the CharProcs one ? | 13:44.20 |
| | I *thought* that already worked.... | 13:44.28 |
| chrisl | Yeh. It does work, but it looks like the currentdict is wrong - no idea why :-( | 13:44.55 |
| kens | Huh. Well at least it usually works. | 13:45.11 |
| | I think I'm goign to put the subr/CharString index out when I write them from cffdisasm, its too hard to find the right one otherwise. | 13:46.05 |
| chrisl | But this file is *really* stupid - if the RIP is < LL2, it builds a Type 3 font instead - so wtf try to use a Type 1 at all........ | 13:46.30 |
| kens | Oh great, bloat the file pointlessly..... | 13:46.49 |
| chrisl | I *really* don't understand what they think to gain by making an invalid type 1 istead of a valid type 3 | 13:48.01 |
| kens | Where does hte file come form ? | 13:48.14 |
| chrisl | It looks hand coded | 13:48.30 |
| kens | Huh. I'd be inclined to write up what a stupid idea that is.... | 13:48.55 |
| chrisl | Yeh, I will, but I think I'll need to fix it anyway | 13:49.24 |
| kens | Of course :-( | 13:49.30 |
| tor8 | Robin_Watts: extra annoying feature of Xcode 4 bugs -- it sometimes doesn't update the executable on the device when running | 13:55.58 |
| Robin_Watts | kens: No. All patterns not of type 2. | 14:18.36 |
| | not of tilingtype 2. | 14:18.41 |
| kens | Umm, what ? | 14:19.09 |
| Robin_Watts | "kens: Only for XPS ?" | 14:19.33 |
| kens | Ah.... | 14:19.37 |
| | I forgot I'd asked | 14:19.42 |
| Robin_Watts | When creating a pattern tile, we bump the xstep and ystep to the nearest integer. | 14:20.18 |
| | (in device space) | 14:20.26 |
| | but, currently, we don't apply that scaling to the actual content of the tile. | 14:20.51 |
| | so (if fill adjust is 0) then we can get empty pixels around the edge. | 14:21.17 |
| kens | Good grief. "If I use -dNOTRANSPARENCY my transparent PDF file comes out wrong...." | 14:30.31 |
| chrisl | ;-) That did cross my mind, too. | 14:30.57 |
| Robin_Watts | kens: Suggested comment: "duh!" | 14:31.26 |
| kens | I had a quick check, it renmders 'mostly black' too, so its not the device. And if you don't specify -dNOTRANSPARENCY its OK. So, "what did you expect ?" | 14:31.33 |
| | I did try to be reasonably polite..... | 14:31.50 |
| Robin_Watts | http://ghostscript.com/~regression/robin/compare9.html <- The first one on that page justifies all the other diffs I reckon :) | 14:32.37 |
| chrisl | Well, that's interesting - changing the locale on Linux changes the behaviour of sscanf()........ | 14:32.47 |
| kens | Robin_Watts : that's a big improvement | 14:33.11 |
| JimPansen | kens: pdfwrite also creates 1x1 rectangles. how much depends on the -r parameter, which is 720 by default | 14:33.55 |
| kens | Yes I saw what you said, but from what input ? | 14:35.18 |
| | I can't comment blind.... | 14:35.33 |
| | Robin_Watts : shame about the file Bug690467.pdf | 14:35.48 |
| Robin_Watts | kens: What number is that ? | 14:36.02 |
| JimPansen | from the "original" ad. looks like a transparency thing | 14:36.16 |
| kens | Robin_Watts : its follows hte file you were poiting at. | 14:36.34 |
| | JimPansen : I can't really comment without seeing the file, and having a command line. | 14:36.50 |
| JimPansen | the original does not show those 1x1 rects | 14:36.56 |
| kens | transparency should be preserved through the conversion, but 'it depends' | 14:37.07 |
| JimPansen | kens: how can i send the file? | 14:37.10 |
| kens | You could open a bug report. | 14:37.16 |
| | Or mail it to me if its not too big | 14:37.30 |
| JimPansen | 4.2MB | 14:38.01 |
| kens | Then just mail it ot ken.sharp@artifex.com | 14:38.15 |
| | I'll need a command line too. | 14:38.24 |
| Robin_Watts | kens: ah. well, that's exactly the effect that you expect from using a TilingType 1 :( | 14:38.33 |
| JimPansen | k, i'll mail it. it's an ad anyway, so there should be nothing confidential about it ;) | 14:39.03 |
| kens | Robin_Watts : yes I agree, was going to say so. Its just a shame that it was nice before | 14:39.06 |
| Robin_Watts | yeah. | 14:39.18 |
| JimPansen | wtf... just got mail from said business partner. they are doing _very_ strage things for that "optimization" ... | 14:40.38 |
| | grepping for the bbox, pdftops, then gs pdfwrite ... | 14:41.57 |
| kens | Seems unlikely that would have any effect, unless pdftops does. I don't know what that uses. | 14:42.33 |
| JimPansen | yeah, i need to check that script... | 14:45.32 |
| kens | pdftops uses Xpdf | 14:50.45 |
| JimPansen | i remember pdftops having created ugly results at some time, presumably by introducing bitmaps or something... | 14:53.41 |
| kens | Possibly, it may have been fixed of course | 14:53.57 |
| JimPansen | seems like that script converts the source prd to eps (via pdftops), inserts the page size in plain postscript, and then uses gs+pdfwrite to create pdf again... | 14:55.46 |
| | *source pdf | 14:55.54 |
| | how ugly is that?! | 14:56.17 |
| kens | Surely not, its supposed to produce PostScript otuput | 14:56.19 |
| | And its supposed to use Xpdf, unless its a script which is different to the pdftops one supplied with xpdf.... | 14:56.46 |
| | The output here doesn't seem to have l;ots of 1x1 rectangles. | 14:57.10 |
| JimPansen | sorry, talking about the business partner's script, which uses pdftops - not about pdftops itself | 14:57.28 |
| kens | Ah. | 14:57.37 |
| | Looks like its the use of PDFSETTINGS=/screen | 15:00.16 |
| | just checking. | 15:00.47 |
| | Yes. If I specify the /screen settings then I get 1 pixel rects if I don't specify that, tehn its OK. | 15:02.05 |
| JimPansen | o.O | 15:02.26 |
| kens | I *think* the problem is that you are using spot colours, and the screen code converts those to RGB so it decomposes an image | 15:02.29 |
| | My advice would be 'don't do that'. | 15:03.33 |
| JimPansen | wow, you're right | 15:06.56 |
| kens | These kinds of problems can crop up, I would generally say don't use any of the presets unless you *really* knwo what they all mean | 15:07.15 |
| JimPansen | "-dPDFSETTINGS=/screen -dColorConversionStrategy=/LeaveColorUnchanged" and everything is fine | 15:07.17 |
| kens | :-) | 15:07.25 |
| | Be aware that you can't always override settings like that. | 15:08.04 |
| | In general the PDFSETTINGS will override anything you put afterwards. | 15:08.22 |
| JimPansen | and about a million times cleaner than pdftops -> fiddling with PS -> pdfwrite | 15:08.28 |
| | oh? | 15:08.48 |
| kens | Its just the way it works. | 15:09.07 |
| | The device gets reset several tiems during startup, and a lot of the parameters get re-read and reset from teh PDFSETTINGS values, if it is set. | 15:09.39 |
| | Perils of legacy code. | 15:09.58 |
| JimPansen | reminds me of the imagemagick cmdline ;) | 15:11.16 |
| kens | For similar reasons I would think.... | 15:11.41 |
| henrys | kens:can you weigh in on hit-tak's patch for 692608 - I had imagined this problem getting fixed in pcl never occurred to me it could be useful to ps/pdf. | 15:20.37 |
| kens | henrys I have it sitting waiting review. | 15:22.07 |
| | Been ahcking CFF CIDFonts all day | 15:22.18 |
| henrys | okay thanks | 15:22.48 |
| Robin_Watts | Just got a quote for chartering a minibus in florida: "Charter cost: $150" (that sounds reasonable). Then it says "$150 per hour, 5 hour minimum" (not so reasonable). "Plus 15% gratuity." (If it's in the bill, it's not a gratuity). | 15:47.55 |
| | so, time to think of a plan b. | 15:48.15 |
| kens | Yikes that's a lot | 15:48.26 |
| Robin_Watts | Aha. | 16:10.18 |
| | mvrhel: Would I be right in thinking that you're our pattern expert ? | 16:10.31 |
| | or does anyone else want to claim the role ? | 16:10.48 |
| mvrhel | good morning. I have dabbled in it a bit here and there | 16:11.10 |
| henrys | mvrhel:you were working with a new customer sometime ago - screens and such he said he went on vacation and we never heard from him again. I can email you the company name - was there followup? | 16:11.11 |
| mvrhel | oh. good question. I had not heard from them in a while | 16:11.41 |
| | henrys: see the private comment | 16:12.24 |
| | last I heard from them, the stochastic screen seemed it it was going to work | 16:12.52 |
| Robin_Watts | mvrhel: I assume the pattern problem you wanted me to look at was the white lines in that xps file in the red grid pattern? | 16:13.07 |
| mvrhel | I will follow up with an email right now henrys to see if all is fine | 16:13.18 |
| | Robin_Watts: yes, that is probably the example I was going to extract for you | 16:13.42 |
| henrys | okay last message I see is Sep 18. | 16:13.44 |
| Robin_Watts | I've extracted it myself, and I understand what's going wrong, and I have a fix, but I'd like to talk it through to see if anyone else can spot a problem with it. | 16:14.31 |
| mvrhel | oh great | 16:14.45 |
| Robin_Watts | Want to write that email, and then let me know when you have time to talk ? | 16:15.09 |
| henrys | We should track this stuff more systematically. When we get a new customer miles should write them down and we review status each month. | 16:15.24 |
| mvrhel | I did not realize they were a new customer | 16:15.51 |
| Robin_Watts | I'll make tea. | 16:16.01 |
| mvrhel | oh I see the last comment was about the ROM footprint | 16:17.27 |
| | let me follow up from that | 16:17.36 |
| | and ask about the screening | 16:17.41 |
| | ok email sent and support CC'd | 16:25.38 |
| henrys | thanks | 16:25.48 |
| mvrhel | I am hoping that since they went dark we had fixed all their issues | 16:25.54 |
| | all the news was good and we had addressed all their issues | 16:26.30 |
| | just never heard anything more | 16:26.38 |
| | Robin_Watts: when the tea has steeped I am ready to chat about patterns | 16:27.08 |
| Robin_Watts | I have tea :) | 16:27.14 |
| | Right. | 16:27.18 |
| | When we go to make a pattern, we allocate a tile. | 16:27.31 |
| | That tile is sized to be the nearest int to the transformed step size. | 16:27.55 |
| mvrhel | ok | 16:28.20 |
| Robin_Watts | (i.e. in this example, our step is 10x10, and that transforms to 7.5x7.5 device pixels, so we make an 8x8 tile). | 16:28.31 |
| mvrhel | right | 16:28.40 |
| Robin_Watts | The problem is we don't change the internals at all, we just draw them. | 16:28.59 |
| mvrhel | yes. I see where this is leading | 16:29.15 |
| Robin_Watts | So the path we draw in this example is 7.5 pixels wide. AS fill adjust is 0, that means it's actually 7 pixels wide. | 16:29.21 |
| mvrhel | right | 16:29.32 |
| Robin_Watts | so we get a white line around the two 'max' edges | 16:29.41 |
| mvrhel | yes | 16:29.46 |
| Robin_Watts | So... I've altered the code so that when it changes the tile size to make it an integer size, it scales the contents to allow for the change. | 16:30.38 |
| mvrhel | ok. ensuring that the tile is adequately filled | 16:31.09 |
| Robin_Watts | Indeed. Code = http://ghostscript.com/~robin/diff.txt | 16:31.28 |
| | That gives (as you can imagine) MANY differences. | 16:31.41 |
| mvrhel | yes | 16:31.47 |
| | :) | 16:31.48 |
| Robin_Watts | but none of them seem showstoppers to me. | 16:31.54 |
| mvrhel | this is what I had done in the xps interpreter for visual brushes | 16:32.26 |
| | and it makes sense to me | 16:32.32 |
| | I mean | 16:32.40 |
| | at my old company | 16:32.48 |
| Robin_Watts | The problem with a change such as this, is that there could be years of experience that had gone into the exact formulation of the pattern setup code, and I've just come along and changed it to something that looks right. | 16:33.02 |
| mvrhel | the only other way to do this that I can see is to make the change only in the XPS interpreter | 16:33.54 |
| Robin_Watts | mvrhel: If you can look at the diff and be happy with it, then I'll feel better about committing it. | 16:34.02 |
| | Well, there is another problem :) | 16:34.12 |
| | The XPS spec says (effectively) that we should be using TilingType 2, not TilingType 1. | 16:34.47 |
| mvrhel | ok. which is 2 and which is 1 | 16:35.03 |
| Robin_Watts | Specifically (thanks to tor for finding this earlier)... | 16:35.09 |
| mvrhel | I have to go look this up | 16:35.10 |
| henrys | we can document an XPS problem as broken and prescribe a patch. The XPS interpreter musn't potentially disrupt other stuff until it means something to us econmomically. | 16:36.04 |
| Robin_Watts | ECMA-388.pdf: 18.7.3: | 16:36.52 |
| mvrhel | what manual is that | 16:37.40 |
| Robin_Watts | Consumers MUST precisely position the tiles specified by the image brush and visual brush. If | 16:37.42 |
| | the specified values result in fractional device pixels, the consumer MUST calculate a running | 16:37.44 |
| | placement-error delta and adjust the placement of the next tile where the delta reaches a full | 16:37.46 |
| | device pixel in order to keep the tiles from being increasingly out of phase as the expanse of | 16:37.48 |
| | the path is filled [M11.9]. Consumers MAY choose any technique desired to achieve this | 16:37.49 |
| mvrhel | oh open xps | 16:37.51 |
| Robin_Watts | requirement, such as linear filtering for seams, stretching of the tile (up-sampling or downsampling), or pre-computing multiple tiles and adjusting behavior according to how the tiles fit | 16:37.51 |
| | on a grid [O11.23]. | 16:37.52 |
| mvrhel | yes. section 11.7.3 in the microsoft manual | 16:38.12 |
| Robin_Watts | i.e. the positioning should always be as accurate as possible, the rendering may be bent slightly. | 16:38.47 |
| | Which sounds like TilingType 2 in postscript terms to me. | 16:39.20 |
| mvrhel | hmmm. are we offset from where we should be when we render compared to the windoze viewer? | 16:40.12 |
| | iirc wasnt that also an issue with the red crosses in that fill? | 16:40.37 |
| Robin_Watts | I haven't checked, but I would bet, yes, if the windows viewer is following the spec. | 16:40.43 |
| mvrhel | yes. so I think you are correct, we should be doing type 2 | 16:41.30 |
| Robin_Watts | OK. The code I changed is in the middle of an "if (TilingType != 2)" clause :( | 16:41.58 |
| | I suspect with tilingtype != 2, we will position the tiles at either 7 or 8 pixels apart. | 16:42.44 |
| mvrhel | hmm. so if we change the tiling type in the xps interpreter set up to do type 2, does it fix the white spaces too | 16:42.44 |
| | yes | 16:42.49 |
| | oh | 16:42.59 |
| Robin_Watts | The 8 pixel apart ones will show the white lines, I reckon. | 16:43.00 |
| | But I haven't tested that yet. Will look now. | 16:43.17 |
| mvrhel | perhaps in the type 2 it does the thing that you are doing for type 1 | 16:43.39 |
| | and then does the 7 or 8 steps | 16:43.57 |
| Robin_Watts | type 2 in the spec says "no distortion to the pattern cell". | 16:44.09 |
| | so I fear it won't, but will test. | 16:44.17 |
| mvrhel | hmm. a 1 pixel distortion over the size of the cell is likely to be ok | 16:44.52 |
| | to ensure proper placement and no dropout | 16:45.06 |
| | s | 16:45.07 |
| Robin_Watts | yeah, I get white lines every other cell :) | 16:45.14 |
| mvrhel | what happens if we just have fill adjust set to 0.5 for the pattern? would that not do the same thing | 16:46.01 |
| Robin_Watts | No. That 'thickens' all the lines in the pattern. | 16:46.17 |
| mvrhel | ok | 16:46.27 |
| Robin_Watts | It would result in the lines getting to the edge pixels, but it has other unwanted effects. | 16:47.01 |
| mvrhel | are you able to construct a postscript pattern case with these sames dimensions | 16:47.04 |
| | and see if it draws with white lines | 16:47.12 |
| Robin_Watts | Probably, yes. | 16:47.14 |
| | it will. | 16:47.18 |
| mvrhel | for us and for Adobe | 16:47.20 |
| Robin_Watts | oh, hold on. | 16:47.33 |
| | PS has the 'any part of a pixel rule'. | 16:47.42 |
| | So fill_adjust = 0.5. | 16:47.49 |
| mvrhel | ah | 16:47.59 |
| Robin_Watts | so a postscript test case would not be identical (unless I set the fill_adjust back down again). | 16:48.15 |
| mvrhel | ok | 16:48.19 |
| Robin_Watts | ponders adding a TilingType 3. | 16:48.35 |
| | oh, there is a 3. | 16:48.45 |
| mvrhel | that is one option. | 16:48.46 |
| | ok 4 | 16:48.51 |
| Robin_Watts | Well a TilingType 99 :) | 16:48.53 |
| mvrhel | yes | 16:48.56 |
| | another approach would be to have the xps interpreter set the transformation matrix to do the ajustment | 16:49.28 |
| Robin_Watts | That does what TilingType2 does, but with the additional scale applied. | 16:49.33 |
| mvrhel | 3 does? | 16:49.50 |
| | or 99 will? | 16:50.06 |
| Robin_Watts | mvrhel: 3 is "Like 1, but faster, in some unspecified way" | 16:50.07 |
| mvrhel | when you right it | 16:50.09 |
| Robin_Watts | 99 will. | 16:50.13 |
| mvrhel | ok. yes. that makes sense | 16:50.20 |
| | it sounds to me like this is what is needed, unless we could fudge it in the interpreter | 16:50.54 |
| Robin_Watts | I think we maybe *could* fudge it in the interpreter, but it feels like the wrong place to fudge it. | 16:51.13 |
| | It'd be cleaner in the graphics lib. | 16:51.27 |
| mvrhel | ok. I am fine either way. | 16:51.40 |
| | I just think it would be less coding and easier in the interpreter | 16:51.59 |
| Robin_Watts | I'm of the opinion we should put my fix in anyway. | 16:52.01 |
| | mvrhel: I was thinking exactly the opposite :) | 16:52.11 |
| | http://ghostscript.com/~regression/robin/compare8.html <- The top diff on that page justifies it to me :) | 16:53.01 |
| | There are others that don't look quite as nice, but no regressions that outweigh that one, IMHO. | 16:53.35 |
| mvrhel | oh wow | 16:54.08 |
| | yes I agree | 16:54.15 |
| | thats crazy | 16:54.24 |
| Robin_Watts | It really hurts my eyes to look at that for too long :) | 16:54.57 |
| mvrhel | how does Adobe distill that one? | 16:55.03 |
| | or render it I mean | 16:55.11 |
| | with AA off | 16:55.22 |
| | oh that is PS | 16:55.31 |
| | let me look | 16:55.46 |
| Robin_Watts | badly. | 16:57.20 |
| mvrhel | so it has the jaggy lines | 16:57.20 |
| | so shouldnt we? | 16:57.31 |
| Robin_Watts | Maybe :( | 16:58.28 |
| mvrhel | I am thinking that we should push forward with a type 99 then which follows the XPS requirements | 16:59.13 |
| Robin_Watts | yeah. | 16:59.19 |
| | Rather than scaling, I could maybe translate slightly to move the pattern to be centred. | 16:59.59 |
| mvrhel | Looking at what Adobe does with the type 1 I am not sure you should commit your patch | 17:00.01 |
| Robin_Watts | no, I'll certainly hold off on it. | 17:00.16 |
| mvrhel | I think the scaling by a pixel over the size of the tile is fine | 17:00.40 |
| | actually it will be less than a pixel | 17:01.10 |
| Robin_Watts | If the pattern is 7.5 pixels wide, and the tile is 8, and I translate by (8-7.5)/2 = 0.25 then the 'covers the centre of the pixels' rule will do what we want. | 17:01.41 |
| | with possibly less distortion than the scaling would introduce. | 17:02.11 |
| mvrhel | but I thought it ended up making thicker lines? | 17:02.31 |
| Robin_Watts | I'm not suggesting changing the fill_adjust. | 17:02.55 |
| | The fill adjust moves us from the "covers the centre of the pixel" rule to the "any part of a pixel" rule. | 17:03.25 |
| mvrhel | oh | 17:03.31 |
| | oh I see you are doing a minor translation to make sure you cover the centers | 17:03.52 |
| | ok | 17:03.53 |
| Robin_Watts | I'm saying that if we just translate by (in this case) 1/4 of a pixel, we get what we want with the existing rule. | 17:03.58 |
| mvrhel | yes | 17:04.01 |
| Robin_Watts | Looks like a 12 passenger minivan thing can be had for 70quid a day. That might be the best option. | 17:17.47 |
| mvrhel | yes that seems reasonable | 17:18.06 |
| Robin_Watts | got to get to the airport and back to pick it up, but still looking like a good option. | 17:19.05 |
| mvrhel | right | 17:19.17 |
| kens | Sounds good. | 17:20.40 |
| | I have to go, night all | 17:20.43 |
| Robin_Watts | May be easier to hire 2, 8 person minivans, cos we can pick them up from just south of the hotel. | 17:27.33 |
| mvrhel | oh. yes | 17:32.41 |
| Robin_Watts | A TilingType of 99 may produce problems when pdfwriting an xps file. | 17:45.27 |
| | mvrhel: You here ? | 18:07.58 |
| | How about, instead of doing a new tilingtype, I just move to using tilingtype 2, and make the tilingtype 2 code do the translation when fill adjust is 0 ? | 18:09.23 |
| mvrhel | sorry. I am here now | 18:21.25 |
| | Robin_Watts: that makes sense | 18:21.58 |
| Robin_Watts | marcosw_: What are your movements in Miami? | 18:32.28 |
| marcosw_ | Jill and I are just discussing Miami. I think we are considering Key West for 3 days before the meeting. | 18:33.01 |
| Robin_Watts | ok. so you'd presumably not be up for the everglades thing. | 18:33.42 |
| | alexcher: same question. | 18:33.56 |
| marcosw_ | I was wondering what the everglades thing is. Being eating by alligators and bitten by large mosquitoes? | 18:34.19 |
| | OTOH, I've always wanted to go on an airboat. | 18:34.33 |
| Robin_Watts | Plan is for an unspecified number (11+ at the moment) to go to the everglades and do an airboat ride, see alligators etc. | 18:35.34 |
| | IF we're having to hire cars etc to do it, then we might as well go from there to Key Largo for the rest of the day (people can snorkel/do glass bottom boat rides etc as they see fit) then back to the hotel | 18:36.19 |
| | Plan is to do it on the thursday - but I need to know numbers to organise it. | 18:37.33 |
| marcosw_ | What time would the THursday being eating by alligator adventure begin? | 18:42.11 |
| Robin_Watts | marcosw_: Earlyish because we'd want to get Key Largo in the same day. | 18:43.27 |
| | (leaving hotel as soon as we can get cars after breakfast I guess) | 18:44.02 |
| | If you're going to have a car anyway, then you could always meet us there. | 18:44.43 |
| marcosw_ | Are people leaving Miami to go home on Saturday afternoon or Sunday? I can't find any good flights that leave after 3:00pm on Saturday. | 18:49.58 |
| mvrhel | I am leaving saturday around 5 or 6 | 19:05.34 |
| | I think ray is leaving saturday too | 19:06.22 |
| | henrys: got an auto reply from the European customer. Out of the office until the 8th. When do these guys work | 19:20.47 |
| | lunch time | 19:21.07 |
| Robin_Watts | mvrhel: http://ghostscript.com/~regression/robin/ | 19:37.30 |
| | 17 looks broken still (though I could believe the patch improves it) | 19:42.03 |
| | Page 14 of file 17 looks very broken | 19:43.14 |
| | oh, right. It's the pdfwritten one that still looks broken even with my fix. I guess that's to be expected. | 19:44.35 |
| | OK. I'm going to claim that as a win. Could I ask you to cast your eye over http://ghostscript.com/~robin/diff.txt, and if you are OK with that I'll commit it. | 19:48.04 |
| | The slightly worrying thing about the patch is that I've had to add gs_translate_untransformed. | 19:48.33 |
| | Whenever I have to add a function like that, it worries me - does the absence of that function imply I'm doing something the wrong way? | 19:49.08 |
| | marcosw_: We are flying out sunday night (as I believe ken and chrisl are) | 19:49.35 |
| | I guess, if we *could* do it in the xps interpreter it'd mean that pdfwritten xps files would look better. | 19:50.46 |
| mvrhel | that is true | 19:53.00 |
| | an advantage of the interpreter approach | 19:53.14 |
| | hold on | 19:56.01 |
| | bbiab | 19:56.02 |
| | Robin_Watts: I wonder why number 3 is missing the grid in the middle | 19:57.55 |
| | number 2 (the xps -> pdf -> ppm) has thick lines and number 3 the xps-> ppm has no lines | 19:59.07 |
| | the rendering in windoze has thin lines | 19:59.35 |
| | there are clearly improvements though in a lot of them | 20:02.01 |
| henrys | mvrhel:yes these euro vacations are really something else as far as I can tell. | 20:18.09 |
| Robin_Watts | mvrhel2: Good point re: 3. | 20:20.03 |
| | Maybe I've shifted it the wrong way in that case? | 20:20.37 |
| | Unless you decide that you want to try doing it in the interpreter, I'll look into that on monday. | 20:21.02 |
| mvrhel | I have to head out for a bit. | 20:29.16 |
| | Robin_Watts: I may look into an interpreter solution this weekened | 20:29.48 |
| | maybe | 20:29.56 |
| | Forward 1 day (to 2011/11/05)>>> | |
IRC Logs