| | <<<Back 1 day (to 2011/12/29) | 2011/12/30 |
| Robin_Watts | Morning tor8. | 11:19.58 |
| tor8 | hey robin. I saw you've been banging your head bloody against transparency :) | 11:22.30 |
| Robin_Watts | yes. | 11:24.00 |
| | I *think* I have it sorted. | 11:24.05 |
| | (Famous last words and all that) | 11:24.19 |
| | but l16.pdf now gives me the results I expect. | 11:24.33 |
| | Just going to run it through sane now. | 11:24.59 |
| tor8 | alright! | 11:30.08 |
| | do you have sane set up? | 11:30.11 |
| Robin_Watts | I think so. | 11:30.35 |
| | Page 1149 of the pdf reference manual goes wrong in 1 case. | 11:40.31 |
| | Let me back out the commit to see if it's related. | 11:40.47 |
| | sane is old/new/diff ? | 11:41.41 |
| | old/diff/new, rather ? | 11:41.50 |
| hroi | hi | 11:46.53 |
| ghostbot | bonjour | 11:46.53 |
| hroi | Im looking for a method to convert pdf pages to images. | 11:47.06 |
| tor8 | Robin_Watts: old/diff/new yet | 11:47.48 |
| | yes* | 11:47.51 |
| Robin_Watts | well, ghostscript and mupdf will both do that. | 11:48.00 |
| | hroi: ^ | 11:48.07 |
| | ok, the diff on page 1149 of pdf_reference17.pdf is unaffected by my change. | 11:50.09 |
| | It's just been a while since I ran sane. | 11:50.18 |
| | tor8: Could you try running the full sane set for me please? | 11:50.32 |
| | (You'll need to enable ATTEMPT_KNOCKOUT_AND_ISOLATED in the top of draw/draw_device.c) | 11:50.56 |
| | Let me push my changes to the master repo. | 11:51.12 |
| hroi | im lost in the ghostscript man pages, dont know where to begin converting | 12:01.05 |
| Robin_Watts | What bitmap format are you hoping for ? | 12:03.03 |
| | gswin32c.exe -sDEVICE=png16m -o out%d.png input.pdf | 12:04.49 |
| | That will convert from input.pdf to out1.png, out2.png, out3.png etc. | 12:05.06 |
| TheTrekhippy | Hi I'm having trouble with the ghostscript plugin for irfanview I've installed the latest available AFPL ghostscript from sourceforge, it still says it can't load the driver when i try to open my .PDF. I've updated the program, uninstalled, reinstalled both irfanview and ghostscript, tried diff version GPL of ghostscript searched forums. | 12:48.10 |
| | Any help with this is very much appreciated. | 12:49.07 |
| Robin_Watts | TheTrekhippy: Can you isolate exactly what gs invocation is being used? | 12:50.14 |
| | i.e. if you can get us a ghostscript command line that fails, we can try to reproduce it and then think about how to fix it. | 12:50.47 |
| TheTrekhippy | I'm not really sure I know how to do that, yet. I will work on it and get back to you. | 12:51.48 |
| | I'm sorry, I don't think I will be able to learn quickly how to use a debugger to find out which command line is malfunctioning. I have done everything recommended at several forums including http://irfanview-forum.de/showthread.php?6360-Ghostscript-error-on-Win-64-bits and to no avail. | 13:01.19 |
| Robin_Watts | Right. So that sounds like an irfanview problem then. :( | 13:03.46 |
| | You could try changing your path to ensure that gswin32c.exe is on the path ? | 13:04.30 |
| | irfanview may be calling gs directly using dll calls. | 13:05.30 |
| | In which case, it's something you'll need to chase with them. | 13:05.41 |
| TheTrekhippy | There are many threads about it. I did specify the path. I see so many threads on it. Some say the fix was using the 32bit program, I have. Some say specify the path to that plugin So I did some say install the GPL version, some say the AFPL...Even using the latest versions of everything. Windows 7 os | 13:07.03 |
| | I guess it's just the rough edges of using free software. | 13:07.53 |
| | I don't get paid enough to learn how to do command line debugging myself. | 13:08.17 |
| | "uninstalled AFPL 8.54 and installed GPL 8.63." is one guys advice, and I don't know how to really clean up the registry on windows 7 seems like a dangerous thing for me to try myself. I'll just go another way I guess. Thanks. | 13:12.54 |
| Robin_Watts | BT have decided that to fix my ADSL problems they need to do a "Twisted Pair Move" (i.e. move my connection from one board to another in the exchange) | 14:27.19 |
| | If I suddenly drop off the internet between now and the 3rd january, that'll be why. | 14:27.38 |
| malc_ | Robin_Watts: hi. outlines do not quite work. | 14:57.18 |
| Robin_Watts | malc_: Ah, you're back. | 14:57.28 |
| | I was going to ask you to test the changes that made it to the main repo this morning, but evidently you already have... | 14:58.01 |
| | In what way don't they work ? | 14:58.11 |
| malc_ | well.. n1570.pdf one has one outline item with down and page set to 0 | 14:58.48 |
| | pdf_reference-1.7.pdf one item.. down = 0, title = Contents.. | 14:59.04 |
| Robin_Watts | pages are numbered from 0 in outlines, I believe. | 14:59.31 |
| malc_ | nope | 14:59.37 |
| Robin_Watts | What's down ? | 14:59.48 |
| malc_ | erm.. a field in fz_outline :) | 15:00.18 |
| Robin_Watts | Right. | 15:01.06 |
| | Isn't down always NULL currently? | 15:01.15 |
| malc_ | next is NULL too | 15:01.20 |
| | no, it was correctly set in previous revisions | 15:01.34 |
| Robin_Watts | No, you're right. I take that back. | 15:02.13 |
| malc_ | "0x10a0e3d8 (nil) (nil) 4" pdf_reference_1-7.pdf | 15:02.39 |
| | (nil) (nil) are down and next respecitvely | 15:02.53 |
| | page 4 is incorrect for this outline item too (Contents) | 15:03.13 |
| | Robin_Watts: what OS are you under btw, if it's Linux perhaps it would be simpler for you to just compile and test my program yourself? | 15:04.47 |
| Robin_Watts | malc_: Windows, normally. | 15:05.21 |
| | I'm in the middle of debugging something else. | 15:05.32 |
| | give me a mo to context switch. | 15:05.40 |
| malc_ | in any case i wouldn't want to put you into ordeal of trying to build things under Windows, it's hard even for me | 15:06.03 |
| Robin_Watts | So, let me look at the outlines loaded for pdf_reference16.pdf | 15:06.07 |
| | 17, sorry | 15:06.18 |
| tor8 | Robin_Watts: there's a -l mode to pdfdraw that you can use to test outlines | 15:08.26 |
| Robin_Watts | Oh, I see what I cocked up. | 15:08.36 |
| | It was a last minute change I made to avoid recursion. | 15:08.47 |
| | Stupid. Stupid. Stupid. Sorry. | 15:08.58 |
| | malc_: Does http://ghostscript.com/~robin/malc.patch solve it for you? | 15:11.29 |
| malc_ | Robin_Watts: yep, thanks.. page numbers are not what they are used to be though | 15:12.47 |
| Robin_Watts | Off by 1 ? | 15:12.59 |
| malc_ | aye | 15:13.29 |
| Robin_Watts | pdf/pdf_annot.c line 45 | 15:14.00 |
| | I thought they were supposed to be 0 indexed. | 15:14.10 |
| | pdf_find_page_number would seem to return pages indexed from 0. | 15:14.47 |
| tor8 | Robin_Watts, malc_: I (relatively recently) changed all page numbers in all API:s to be consistently 0-indexed | 15:18.18 |
| Robin_Watts | Ah, ok. So I'm doing the right thing. | 15:18.35 |
| malc_ | oh.. shrug | 15:18.35 |
| Robin_Watts | malc_: I'll get that fix pushed later today, thanks. | 15:18.52 |
| malc_ | Robin_Watts: well.. bad news aren't over.. | 15:19.14 |
| | i can't seem to get "fine" part working :) | 15:19.25 |
| Robin_Watts | malc_: In what way ? | 15:19.47 |
| malc_ | Robin_Watts: well y's in pdf_ref... are all the same(0).. x's are different though | 15:21.26 |
| Robin_Watts | malc_: Damn. Let me look again... | 15:22.06 |
| malc_ | it looks as if they were swapped somewhere | 15:23.42 |
| Robin_Watts | pdf/pdf_annot.c line 64. | 15:23.45 |
| | Change 1+16 to 1+2+16 | 15:23.50 |
| malc_ | nope | 15:25.21 |
| Robin_Watts | Give me an example that's wrong with that change. | 15:25.46 |
| malc_ | pdf_reference | 15:26.02 |
| Robin_Watts | Right, but which entry ? | 15:26.21 |
| malc_ | all of them | 15:26.30 |
| | ld.gotor.lt.y's are all zeroes | 15:26.52 |
| Robin_Watts | Right. | 15:27.04 |
| malc_ | and if i swap x and y, fine positioning works as expected | 15:27.06 |
| Robin_Watts | The entries in that file are 'XYZ' entries. | 15:27.23 |
| | So look at the 'flags' word for each outline. | 15:28.01 |
| malc_ | i do | 15:28.12 |
| Robin_Watts | and you should see bits set. | 15:28.14 |
| malc_ | it's 67 | 15:28.16 |
| Robin_Watts | Right. So 64 + 1 + 2 | 15:28.33 |
| | 1 tells you that lt.x is valid. | 15:29.03 |
| | 2 tells you that rb.y is valid. | 15:29.12 |
| malc_ | ah.. let me adjust my code then.. since i was only using the lt part | 15:29.47 |
| Robin_Watts | 64 tells you that the value contained in rb.x is actually a zoom value. | 15:29.58 |
| malc_ | erm.. 2 tells me that lt.y is valid | 15:30.26 |
| | fz_link_flag_t_valid = 2, /* lt.y is valid */ | 15:30.37 |
| | not rb.y | 15:30.40 |
| Robin_Watts | OK. I cocked up again :( | 15:32.44 |
| | OK. Change back from 1+2+16 to 1+16 again :) | 15:34.51 |
| malc_ | still getting zeroes in y's | 15:38.59 |
| Robin_Watts | malc: Yes, my code is still broken. Give me a mo. | 15:39.18 |
| | malc_: OK. Revert to 1+16. then pdf/pdf_annot.c lines 143 and 148 should be setting lt.y, not lt.x | 15:44.04 |
| malc_ | Robin_Watts: works now, thanks again | 15:47.11 |
| Robin_Watts | malc_: Fab, and sorry (again!) | 15:47.26 |
| malc_ | "Fab, mo".. trying to avoid carpal tunnel syndrome? | 15:47.49 |
| tor8 | malc_: no, he actually speaks like that too ;) | 15:54.41 |
| malc_ | tor8: and taking "1+2+16" into consideration i'd say it's a symptom.. of something ;) | 15:55.45 |
| Robin_Watts | I wondered about using an enum there. | 16:08.43 |
| | but it's only within 1 function, and the enum names would have to be HUGELY unwieldy to avoid being confusing. | 16:09.23 |
| tor8 | Robin_Watts: a file-local or function-local enum? | 16:10.42 |
| | with short concise names than don't need to be long but are better than magic numbers | 16:11.02 |
| Robin_Watts | a function local enum | 16:13.40 |
| | And the problem is I couldn't come up with short concise names that remained meaningful. | 16:13.57 |
| | but yes, I feel guilty about it. | 16:14.09 |
| | I'll try and fix that before I push the fixes. | 16:15.01 |
| malc_ | Robin_Watts: if you want to stop feeling guilty i suggest reading some of D.J. Bernstein's code.. qhasm for instance | 16:16.17 |
| Robin_Watts | Actually, I should be immune to guilt after looking in depth at the rop code :) | 16:17.19 |
| malc_ | rop? raster operations? | 16:17.52 |
| Robin_Watts | in gs, yes. | 16:18.01 |
| malc_ | hehh | 16:18.27 |
| Robin_Watts | tor8: Found the hivemind problem, I think. | 16:24.42 |
| | And the pixel.pdf problem. Woo Hoo! | 16:25.44 |
| | malc_: Fixes pushed. | 16:43.02 |
| | tor8: Could you rerun the big sane test again please? | 16:43.20 |
| tor8 | Robin_Watts: running | 16:46.41 |
| Robin_Watts | Thanks. | 16:46.48 |
| tor8 | Robin_Watts: reload the page I linked before for new results | 16:58.43 |
| malc_ | Robin_Watts: works | 16:59.11 |
| Robin_Watts | tor8: Thanks. | 17:00.26 |
| | malc_: Fab. | 17:00.29 |
| | tor8: Woo Hoo! | 17:02.03 |
| | Shall we enable it by default then ? | 17:02.12 |
| malc_ | tor8, Robin_Watts: not that i care about xps, but.. mupdf segfaults on Office2007_Powerpoint_Drawing_Fills_Texture.xps (and for all xpses i've tried: "warning: cannot process FixedDocument rels part") | 17:03.18 |
| Robin_Watts | malc_: Is that a new problem? | 17:22.11 |
| | I'm trying to download the file now, but having problems with my ADSL line. | 17:22.31 |
| malc_ | Robin_Watts: i've no idea, sorry | 17:22.46 |
| | Robin_Watts: outlines like this "[ 2917 0 R /XYZ 126 486 null ]" do work but "[ 5076 /XYZ 69 720 0 ]" produce off by one page number | 17:28.58 |
| Robin_Watts | The second one gives what page number ? | 17:30.00 |
| | 5075 ? | 17:30.05 |
| malc_ | yes | 17:31.21 |
| Robin_Watts | So that's correct. | 17:31.26 |
| | But the first one is giving what? And should be giving what ? | 17:32.01 |
| | (Without a file to refer to, I can't comment) | 17:32.10 |
| malc_ | Robin_Watts: point being.. the same code works for one file (pdf_ref..) and produces off by one in another "ECMA-376, Second Edition, Part 1 - Fundamentals And Markup Language Reference.pdf" | 17:33.31 |
| | evidently they take different paths in pdf_anot.c:56 | 17:34.06 |
| | s;anot;annot | 17:34.15 |
| Robin_Watts | malc_: Right. Them giving different results is bad, yes. But I believe you have mischaracterised the problem. | 17:34.45 |
| | [5076 /XYZ 69 720 0] SHOULD give a page number of 5075. That's correct. | 17:35.10 |
| | If your viewer is mishandling it, then it's a bug in the viewer. | 17:35.23 |
| | If there is a mismatch in the numbers being given by the parsing code for the 2 different styles, then I need to fix that. | 17:36.19 |
| malc_ | there's a mismatch the viewer is okay with pdf_reference (and C standard) and not okay with ecma document | 17:40.09 |
| Robin_Watts | For the ecma document, if you click a link, do you go to the page before, or the page after you're supposed to? | 17:40.44 |
| | And what viewer? | 17:40.48 |
| malc_ | Robin_Watts: links are off by one too, the viewer is my own | 17:41.38 |
| Robin_Watts | OK. I'll ask again: | 17:42.24 |
| malc_ | FWIW clicking on a link in stock mupdf is off by one too | 17:42.28 |
| Robin_Watts | For the ecma document, if you click a link, do you go to the page before, or the page after you're supposed to? | 17:42.34 |
| malc_ | the page before | 17:42.53 |
| Robin_Watts | I'm confused here. | 17:48.38 |
| | tor8: You about? | 17:48.42 |
| | In pdfapp.c we do: app->outline = pdf_load-outline(app->xref) BEFORE the pages are loaded. | 17:49.03 |
| | hence we can't resolve destinations of links. | 17:49.14 |
| malc_ | line 57 (-1 part) of pdf_annot.c is wrong i believe | 17:52.02 |
| Robin_Watts | I'd like to understand why. | 17:53.25 |
| | The page numbers given in pdf files are 1 based, right ? | 17:53.37 |
| | [5076 /XYZ 69 720 0] means 'goto page 5076 where the first page is 1', right ? | 17:54.18 |
| tor8 | pages are referenced by object numbers all throughout pdf I believe | 17:54.23 |
| Robin_Watts | If that's true, then a) why do we have code in pdf_parse_link_dest to allow for pages being ints, and b) why does the ecma document that malc_ refers to use numbers? | 17:58.07 |
| | malc_: Ah! | 17:58.36 |
| | For *remote* goto actions, we can have ints as numbers. | 17:58.50 |
| | And they are numbered from 0. (page 655 of the 1.7 spec) | 17:59.07 |
| | So you're right, and I'm once again wrong. | 17:59.19 |
| | Just remove the -1. | 17:59.22 |
| | malc_: Fixed push. Thanks/Sorry. | 18:01.23 |
| malc_ | Robin_Watts: works now, thanks | 18:02.25 |
| tor8 | Robin_Watts: page 582 only mentions page objects for (internal) destinations | 18:04.46 |
| malc_ | Robin_Watts: btw, i've looked at your scaling code and was wondering does the asm functions really improve things that much? (even when using armcc?) | 18:05.02 |
| Robin_Watts | malc_: OhGodYes. | 18:05.53 |
| malc_ | Robin_Watts: because they (gcc/armcc) are not smart enough to switch out of thumb? | 18:06.50 |
| Robin_Watts | I can't offer explicit timings to back that up (I had some, but didn't keep 'em), but my memory is that it saved a lot. | 18:07.01 |
| | It's not the thumbness that's the problem. It's the compilersAreCrapness. | 18:07.16 |
| malc_ | hah :) | 18:07.28 |
| | i was pondering of writing altivec code to do things, but am not sure i want to go the whole 9 yards switching to assembly | 18:07.56 |
| Robin_Watts | has been frobbing ARM code since 1988ish, so it's not a problem for me :) | 18:08.14 |
| malc_ | was (probably) still writing basic in 1988ish.. | 18:09.12 |
| Robin_Watts | oh, I was writing BASIC too :) | 18:09.27 |
| Robin_Watts | used to work with Sophie Wilson (who both wrote BBC BASIC and designed the ARM instruction set) | 18:09.59 |
| malc_ | hah :) | 18:10.49 |
| | they say that armcc is head and shoulders above gcc, so that's why i wondered.. the routines you assemblized do not strike me as particularly hard to optimize.. then again most of the speed improvements i've seen when optimizing code of my own came mostly from rearranging stuff to be more cache friendly.. | 18:12.32 |
| | all in all i think ARMs OOE sucks | 18:12.42 |
| Robin_Watts | OOE ? | 18:13.04 |
| malc_ | out of order execution | 18:13.35 |
| Robin_Watts | ARM is very simple. It's endowed with many registers, and the key to making it work fast is to avoid putting stuff down and to make use of conditional execution. | 18:14.13 |
| | Conditional execution avoids the need for OOE. | 18:14.25 |
| | BUT... no one has yet written a compiler capable of using conditional execution in any smart way. | 18:14.47 |
| | And the vast majority of compiler/optimisation research has gone into producing compilers where registers/memory are essentially equivalent (mentioning no x86s). | 18:15.28 |
| malc_ | endowed is this a joke? i have twice as many here! granted one is reserved, but SP,IP on arm are too! :) | 18:15.34 |
| Robin_Watts | malc_: What architecture? | 18:16.09 |
| malc_ | powerpc | 18:16.19 |
| Robin_Watts | You mentioned a joke :) | 18:16.28 |
| malc_ | yes arm is a joke compared to ppc (register count wise :) | 18:16.55 |
| Robin_Watts | but yes OOE is not a strength of the ARM. | 18:17.33 |
| | (or rather, it's not a strength of traditional ARM implementations) | 18:17.53 |
| malc_ | conditional execution is part of the reason (i've heard), that's why it's (mostly) gone in arm64 | 18:19.42 |
| Robin_Watts | sobs | 18:20.22 |
| | malc_: xps should be fixed now. | 18:22.18 |
| | You'll still see the warnings on every file though - tor8 you here? | 18:22.47 |
| malc_ | fixed indeed | 18:23.18 |
| tor8 | arm64 looks like a disaster... from what little I've seen reported on it | 18:23.20 |
| Robin_Watts | I'm refusing to acknowledge it's existence. It'll go away if I don't look at it. | 18:23.45 |
| tor8 | Robin_Watts: same way I feel about the C11 standard that came out last week | 18:24.16 |
| malc_ | tor8: what's wrong with it? | 18:24.32 |
| | (apart from the fact that none has yet fully implemented even c99) | 18:24.52 |
| Robin_Watts | tor8: At the moment, we print whenever we fz_throw | 18:25.13 |
| | We should probably move to a paradigm when we print when we dispose of an error. | 18:25.59 |
| | That is, so when we catch, we fz_handle() it to get rid of it silently, or fz_report() to print it out. | 18:26.26 |
| | That would solve the spurious warnings on xps. | 18:26.50 |
| tor8 | Robin_Watts: I don't oppose in principle, but the xps code could do with some rewiring to get rid of the throw/catch that happens in the normal case | 18:27.39 |
| Robin_Watts | fair enough. | 18:29.20 |
| | tor8: I may have missed an answer earlier. Do you think we should enable the knockout/isolation/blending code by default? | 18:31.08 |
| tor8 | a fz_report to print the latest thrown exception in a context | 18:31.10 |
| Robin_Watts | I think we should. | 18:31.14 |
| tor8 | bu I don't think we need a special call to discard an error message | 18:31.51 |
| | Robin_Watts: does it affect performance? | 18:31.53 |
| Robin_Watts | One idea would be to have it so we always print the error on exit from an fz_catch unless we fz_handle. | 18:32.05 |
| | Dunno if that's doable. | 18:32.11 |
| | Probably not. | 18:32.26 |
| tor8 | Robin_Watts: I'd rather see all messages being printed in debug builds, and only on fz_report in release builds | 18:32.39 |
| Robin_Watts | For files that do not use isolated or knockout, there will be no performance hit. | 18:33.19 |
| | For files that do there will, but we'll get them right ;) | 18:33.40 |
| tor8 | well then I think we should turn it on :) | 18:33.55 |
| | it certainly made the test cases we have improve | 18:34.04 |
| Robin_Watts | I will do so. I'll leave it as a #define so people can disable it if they object (or if we find problems). | 18:34.23 |
| tor8 | sure | 18:34.34 |
| sebras | tor8 Robin_Watts: I remember an old Office-generated .pdf that had ints as page identifiers for link destinations. I think that is why I added the code. However those links were always of by one, and somehow acroread dealt with that. | 20:14.39 |
| | oh, and I don't know where that old document is now... | 20:15.15 |
| | but if needed I can look for it once my desktop is up and running again... *sigh* | 20:15.41 |
| | Forward 1 day (to 2011/12/31)>>> | |
IRC Logs