| | <<<Back 1 day (to 2014/07/31) | 2014/08/01 |
| pedro_mac | hi folks | 06:47.35 |
| kens | tor8 ping (or chrisl) | 12:03.20 |
| chrisl | kens: pong | 12:03.43 |
| kens | Can you talk with me a minute about bug #695403 ? Its a 45Mb download I'm afraid | 12:04.10 |
| | and you need to see the file | 12:04.18 |
| chrisl | Getting the file | 12:05.13 |
| kens | I think I'm getting there myself without the talk, but.... | 12:05.31 |
| | It looks like the CS is creating a daft xref | 12:05.41 |
| | Its defined as "xref 0 0" | 12:05.54 |
| | Which is an empty subsection | 12:06.03 |
| | However, there is a /Prev entry | 12:06.15 |
| | in the trailer dict | 12:06.20 |
| | And that looks like it references the correct xref. THere'a *also* an XrefStrm, so I guess htis is one of those horrible hacky 'Hybrid'; files | 12:07.50 |
| chrisl | Hmm, can I run this through muclean to make it easier to read, or does that "fix" it? | 12:08.42 |
| kens | I have no idea | 12:08.50 |
| | I suspect it will fix it though | 12:09.02 |
| | I think I'll need to do some digging through pdf_main.ps to see if we are using the xref or xrefstrm. Or nothign because we get confused by an empty xref subsection | 12:09.46 |
| | I'm guessing teh empty section is there purely to turn this into a Hybrid file (ie so they can add a XrefStrm to an existing xref) | 12:10.19 |
| | I suspect this is causing the confusion for the interpreter | 12:10.35 |
| chrisl | Yeh, and I have a vague memory that is actually legal (if daft) | 12:10.48 |
| kens | I may come back in a bit chrisl, but thanks for now :-) | 12:10.55 |
| | I'm fairly sure its legal :-( | 12:11.02 |
| | Now I just have to figure out what the PDF interpreter is doing. | 12:11.13 |
| | Since the OP is using GS commercially (but probably legally) without a licence or support contract, I'm not particuarly in a hurry to fix this one. The file runs anyway and if the warning breaks their system, then they need to fix *their* system :-) | 12:12.21 |
| chrisl | mupdf doesn't like it either "error: xref range marker must be positive" | 12:12.52 |
| kens | Ooh, then I'll add a MuPDF bug after I get this fixed. Altering the xref offset should fix it. | 12:13.17 |
| | Chaning the startxref from 47287520 to 46869265 ought to work I htink | 12:13.48 |
| | It gets rid of the warning in GS | 12:14.35 |
| | (which is a good indication of the problem) | 12:14.51 |
| | Hmm, my version of MuPDF (quite old) is happy with the original | 12:15.28 |
| | Hmm, MuPDF 1.0 :-) | 12:16.15 |
| | 1.4 rc1 works with it too | 12:16.44 |
| | But when I exit it says the file has unsaved changes | 12:17.28 |
| tor8 | kens: yeah, you get that "unsaved changes" prompt if the file has been repaired | 12:28.02 |
| kens | Ah well I guess that's it. Oddly it seems to be the trailer dict that GS is complaining about, not the zero entry xref section | 12:31.29 |
| tor8 | kens: still downloading ... the wifi to my workstation is dog slow :( I think I need to replace my router | 12:31.59 |
| kens | I wasn't hugely impressed tehat they uploaded a huge file with 100 pages in to demonstrate the problem, which they claim is widespread. I suspect its actually a setting in the CS they are using, I'm sure you don't *have* to save a hybrid file. | 12:32.50 |
| | Ah, if we find a trailer entry, and the number of Objects encoutnered so far is 0, we throw an error. That's quite deliberate, I wonder if it was added in response to some specific problem | 12:34.31 |
| | ROFL and now I get a warning 'length of some xref entries is not equal to 20 bytes.... | 12:35.51 |
| | OK that was my fault, put the exit before a pop instead of after. If I remove the specific check for 0 objects when we find a trailer then the warning goes away. | 12:38.35 |
| | I guess I'm going to have to do that as a fix. | 12:38.57 |
| | Hmm, so I added the code to detect xref with no entries for Bug #694342, so that we would rebuild the PDF file. | 12:59.13 |
| tor8 | kens: hm, I don't see any warnings with mupdf on the file | 13:29.30 |
| kens | tor8 wasn't me, MuPDF worked for me, chrisl said he saw problems | 13:29.47 |
| tor8 | kens: ah, right. | 13:30.16 |
| kens | I think I have a fix now for GS which still works for Bug #694342 as well (sigh, xref 0 0 /trailer is valid, xref /trailer isn't....) | 13:30.29 |
| tor8 | kens: I recall fixing something like this problem in mupdf... allowing xref 0 0 | 13:31.27 |
| | that might've been a simple confusion with > and >= in the code though | 13:31.53 |
| kens | It *was* allowed in GS before I made the change to fix a broken tiger.pdf which had "xref /trailer" but no actual xref section values. I chose to regard 0 Objects being defined as invalid, which is what breaks this stupid hybrid file crap | 13:32.25 |
| tor8 | kens: ah! | 13:32.43 |
| kens | :-( | 13:32.53 |
| | So now there's yet more jiggery pokery in the xref decoding to look and see if we have a genuinely empty section (0 0) or a missing section..... | 13:33.31 |
| tor8 | I haven't seen these 'hybrid' files before, what are they? | 13:34.32 |
| kens | Its to do with XRef streams. A Hybrid file has both and Xref Stream *and* a regular xref, for the benfit of readers prior to PDF 1.5 | 13:35.04 |
| | WHich seems like a recipe for disaster to me..... | 13:35.22 |
| chrisl | tor8: the mupdf I tried is not up to date.... | 13:36.12 |
| | kens: I'm going out for a bit in a few minutes - not sure when I'll be back. If I get back at a reasonable time, I'll call you then - if not, have a good weekend! | 13:37.32 |
| kens | OK see you chrisl | 13:37.42 |
| tor8 | kens: that seems ... stupid. why bother with an Xref stream if you're also going to have a regular xref? it's not like the new xref streams serve any other purpose than shaving a few bytes on the file size..... | 14:43.32 |
| kens | tor8 so that readers which can't handle PDF 1.5 can read the file, as well as those that *can* handle PDF 1.5. I'm assuming it was intended for 'short term' use when PDF 1.5 was released, ten years ago..... | 14:44.23 |
| tor8 | kens: it's still bafflingly useless... | 14:44.50 |
| kens | I've commented in the bug thread that whoever is producing such files should stop doing it | 14:44.53 |
| tor8 | but well, that's adobe for you :) | 14:44.56 |
| | Forward 1 day (to 2014/08/02)>>> | |
IRC Logs