| | <<<Back 1 day (to 2013/06/26) | 2013/06/27 |
| kens | wants to know why support has gone mad since I took over the PDF & PS interpreters | 08:43.30 |
| Robin_Watts | People are surprised by having someone that actually looks at/comments on/closes the bugs rather than just ignoring them. | 08:44.15 |
| kens | :-( | 08:44.48 |
| Robin_Watts | So Amazon has just launched a new service. | 10:16.52 |
| | For every CD you buy from them they give you access to the music automatically in their cloud player. | 10:17.13 |
| | And they are back dating it to every CD you've ever bought from Amazon. | 10:17.25 |
| kens | Hmm, that's several for me then I guess | 10:17.38 |
| Robin_Watts | (and vinyl, for luddites like chrisl :) ) | 10:17.45 |
| kens | has vinyl also, but all old stuff. magnetic tape too | 10:18.11 |
| Robin_Watts | I've pretty much only ever bought music from Amazon since they opened. 1444 songs :) | 10:18.16 |
| | kens: I rebought a load of old tapes etc as CDs from Amazon. | 10:18.57 |
| kens | Robin_Watts : I rebought some vinyl, the tapes are mostly bootlegs, and so not really available on CD ;-) | 10:19.31 |
| | I also ripped a bunch of vinyl myself, if the record was in decent condition | 10:19.59 |
| | Looks like our pattern code has a major flaw | 10:20.39 |
| | and its making my head hurt.... | 10:20.52 |
| Robin_Watts | *a*. So hopeful :) | 10:20.56 |
| kens | The clamping code seems to assume that the pattern co-ordinate space is the same orientation as the default PostScript co-ordinate space | 10:21.42 |
| | And it tries to clamp the pattern by tiling it, starting from botto left, and prcoeeding to top right | 10:22.07 |
| Robin_Watts | kens: Can I distract you from that for a moment to give your head a chance to recover? | 10:22.23 |
| kens | Robin_Watts : I'd welcome a distraction | 10:22.35 |
| Robin_Watts | So, linearised PDF... | 10:22.41 |
| kens | Oh god | 10:22.48 |
| kens | think shat is worse | 10:23.01 |
| | err thinks that is worse | 10:23.13 |
| Robin_Watts | if I download http://ghostscript.com/~robin/pdf_reference17.pdf in a web browser, the first page appears first, as you'd expect. | 10:23.28 |
| kens | OK | 10:23.38 |
| Robin_Watts | but then all the other pages appear one by one as they download. | 10:23.41 |
| kens | That seems reasonable, though how do you mean they 'appear one by one' ? | 10:24.11 |
| Robin_Watts | The page tree is right at the end of the file, so how is it finding the other pages? | 10:24.12 |
| | I mean, as more of the file downloads, more pages pop up. | 10:24.25 |
| | it's not just "the first page" then "all the rest" | 10:24.35 |
| kens | Because the linearisation has some stuff about pages in it doesn' it ? The Pages tree is irrelevant I think | 10:24.38 |
| Robin_Watts | The hint stream tells us where pages are. | 10:24.55 |
| kens | let me refresh my memory from the PDFRM | 10:24.56 |
| Robin_Watts | so I thought, "Aha, it's using the hint stream". | 10:25.07 |
| kens | I would have expected that, yes | 10:25.18 |
| Robin_Watts | So I removed the first 5 bytes of the (flated) hint stream, and replaced them with BALLS | 10:25.27 |
| | http://ghostscript.com/~robin/nohintref.pdf | 10:25.41 |
| | and it STILL gets the pages appearing one by one. | 10:25.51 |
| kens | Not in pdf.js | 10:26.00 |
| Robin_Watts | So I'm forced to conclude that it is NOT using the hint stream. | 10:26.02 |
| | This is Chrome. | 10:26.10 |
| paulgardiner | Amazon seemed to have added cds I bought as presents for other people - bought using their wish lists explicitly for them. | 10:26.11 |
| kens | starts up chrome | 10:26.28 |
| Robin_Watts | paulgardiner: Oh, yes. | 10:26.31 |
| | kens: So... perhaps it's looking for '/Type /Page' and assuming the pages are in order? | 10:26.58 |
| kens | Robin_Watts : that was going to be my next suggestion, but.... | 10:28.03 |
| | It displays the correct number of pages in the scroll bar while still downloading | 10:28.16 |
| | Is that stored somewhere other than the hint stream ? | 10:28.36 |
| Robin_Watts | kens: It is. | 10:28.55 |
| | that's the /N entry in the linearised object. | 10:29.03 |
| kens | OK then that is probably what it is doing, eys | 10:29.06 |
| Robin_Watts | So I need to make my code peek at dictionaries to see if they are /Type/Page | 10:29.35 |
| | Feels... fragile. | 10:29.45 |
| kens | Yes, but... | 10:29.53 |
| | Linearisation sucks, and it doesn't work with compressed xref streams anyway | 10:30.08 |
| Robin_Watts | I've seen you say that before. | 10:30.18 |
| kens | So I think nobody really has ever supported it | 10:30.20 |
| Robin_Watts | Doesn't pdf_reference17.pdf use compressed xref streams? | 10:30.31 |
| paulgardiner | robin_watts: there's a fix for the xref-monotonicity problem on paul/master | 10:30.45 |
| kens | I'd be surprised if it didn't have xref streams | 10:31.01 |
| | But if you linearise it, it may put it down to 1.4 | 10:31.16 |
| Robin_Watts | kens: pdf_reference17.pdf *is* linearised. | 10:31.37 |
| | and it contains an XRefStrm | 10:31.50 |
| kens | I'm pretty sure it was an Adobe document that said xref streams didn't work | 10:32.18 |
| | TBH given that Distiller doesn't properly linearise files either, I wouldn't trust it | 10:32.36 |
| Robin_Watts | It uses an old style xref for the first one in the file (first page), and a compressed one for the next, I think. | 10:32.55 |
| kens | The last one in the file is a reguilar xref | 10:33.17 |
| | And the file is declared as PDF 1.4 in the header | 10:33.36 |
| Robin_Watts | %PDF-1.6 | 10:33.54 |
| kens | Then we are using different files | 10:34.02 |
| | Mine was produced by FrameMaker on 17/10/2006 and modified on 18/10/2006, Producer is Distiller 7.05 (Windows) | 10:34.57 |
| Robin_Watts | I have: PDF-1.6, then a linearised object, then xref <object list/offsets> trailer << .... /XRefStm 186352 ... >> | 10:35.09 |
| | Mine is http://ghostscript.com/~robin/pdf_reference17.pdf | 10:35.26 |
| kens | THis is the head of my file: | 10:36.09 |
| | %PDF-1.4 | 10:36.10 |
| | %âãÏÓ | 10:36.10 |
| | 333147 0 obj <</Linearized 1/L 32431662/O 333152/E 308684/N 1310/T 25768671/H [ 16979 169485]>> | 10:36.10 |
| | endobj | 10:36.10 |
| | xref | 10:36.10 |
| | 333147 816 | 10:36.11 |
| Robin_Watts | I have same details as yours, by a mod date of a month later. | 10:37.01 |
| | Distiller 7.0.5 (Windows) | 10:37.17 |
| kens | Yours is 40k bigger than mine too | 10:37.23 |
| Robin_Watts | kens: It's probably that hint streams are incapable of pointing into compressed object streams. | 10:38.58 |
| kens | Your file has a 'proper' xref at the end too | 10:39.05 |
| Robin_Watts | yeah, but it definitely has an XRefStm in it too. | 10:39.22 |
| kens | Robin_Watts : yes, thst's the problem, it does say so somewhere in the spec | 10:39.25 |
| Robin_Watts | So, if we avoid hint streams, linearised works fine. | 10:39.39 |
| kens | I thougth a linearised file was required to have a hint stream ? otherwise what's the point ? | 10:40.05 |
| | I can't find a XRefStrm in your file | 10:40.46 |
| Robin_Watts | XRefStm, not XRefStrm | 10:41.04 |
| kens | ah, the trailer dict has an Xrefstrm in it | 10:41.10 |
| | yes that | 10:41.18 |
| Robin_Watts | Aha. Page 109 of the spec. | 10:41.47 |
| kens | ah, hybrid | 10:42.19 |
| | I forgot about that hacky kludge | 10:42.29 |
| Robin_Watts | So it's 1.5+ things only. | 10:42.42 |
| | At any rate, at least I understand how this is working now. | 10:42.53 |
| | Thanks for talking this through. | 10:42.58 |
| kens | NP | 10:43.02 |
| kens | heads back to co-ordinate spaces | 10:43.52 |
| tor8 | Robin_Watts: oh lovely. Xcode 5 has stopped shipping a command line compiler... | 10:58.56 |
| | even with the Command Line Tools... | 10:59.05 |
| Robin_Watts | tor8: Surely you jest?!? | 10:59.13 |
| kens | boggles | 10:59.21 |
| Robin_Watts | tor8: Even using xcrun ? | 11:00.40 |
| | http://www.cocoanetics.com/2012/07/you-dont-need-the-xcode-command-line-tools/ | 11:01.05 |
| tor8 | Robin_Watts: hard to tell, I've got both Xcode 4 and 5 (preview) installed | 11:01.09 |
| Robin_Watts | xcode-select | 11:01.20 |
| tor8 | I cannot find the compiler for iOS builds... | 11:02.51 |
| Robin_Watts | xcrun cland -arch armv7 ? | 11:04.07 |
| | xcrun clang -arch armv7 ? | 11:04.11 |
| | xcrun -sdk iphoneos ? | 11:06.33 |
| tor8 | I could try that. in the past I used the same binary as the native Xcode build did, which was a 'gcc' in $PLATFORM_DEVELOPER_BIN_DIR | 11:07.05 |
| Robin_Watts | http://blog.octo.com/en/automating-over-the-air-deployment-for-iphone/ | 11:07.13 |
| tor8 | that directory is now missing bits and pieces. different bits and pieces for the different targets (ios, simulator, macosx) | 11:07.33 |
| Robin_Watts | I feel for you :( | 11:08.14 |
| tor8 | maybe xcrun is the way forward though | 11:08.26 |
| | oh yay, the progress bar in safari on ios7 is 1 pixel high... | 11:10.06 |
| | ... and oh boy, we've got work to do | 11:10.50 |
| | the automagic scrollview adjustments that used to happen when toolbars were shown/hidden behaves differently | 11:11.15 |
| | so now the page jumps up an inch when hiding the toolbars | 11:11.26 |
| kens | ick | 11:11.35 |
| tor8 | Robin_Watts: and a bunch of lock errors | 11:13.31 |
| | Attempt to take lock 0 when held already! | 11:13.32 |
| | Attempt to release lock 0 when not held! | 11:13.32 |
| Robin_Watts | tor8: crumbs. | 11:13.52 |
| tor8 | I don't use multithreading and/or locks in the ios app, so seeing those is suspicious | 11:13.54 |
| Robin_Watts | Lock 0 is the alloc lock. | 11:13.58 |
| tor8 | or ios7 changed how the blocks grand central dispatch crap works... | 11:14.45 |
| Robin_Watts | so either something is failing mid-alloc, or you're getting callbacks on a different thread than before and trying to malloc at that time. | 11:14.48 |
| | tor8: Well, you wanted to escape working on gtk, right? :/ | 11:15.14 |
| tor8 | or they added some automatic threading bullshit | 11:15.15 |
| | well, now I'm *this* much closer to reformatting my mac with windows 8 ..... it'd be an improvement | 11:15.37 |
| | anyway, calling the plain old "clang -arch armv7" seems to work well enough | 11:16.28 |
| | but I've had my fill of apple today. I shan't waste any more energy on updating the ios project for xcode 5 and ios7 today... | 11:16.52 |
| | Robin_Watts: I've got the first shell of an opengl based mupdf viewer up on tor/opengl if you want to take a peek | 11:18.23 |
| | so far it's just rendering with our existing draw device and uploading to a texture | 11:18.33 |
| Robin_Watts | tor8: Cor, that was fast. | 11:18.37 |
| tor8 | and showing that texture as a textured quad | 11:18.50 |
| Robin_Watts | but it's a good first step. | 11:18.50 |
| | tor8: Runs on 'doze? | 11:19.09 |
| tor8 | going to get some basic transforms (zoom and rotate) and page flipping in there | 11:19.10 |
| | Robin_Watts: with msys-git build yes | 11:19.17 |
| | haven't done the win32 project | 11:19.23 |
| | oh, but you need freeglut. I'll upload a copy of freeglut built for windows to casper if you want to give it a spin. | 11:19.48 |
| Robin_Watts | I will try to look at that later today (mid progressive crap at the moment). | 11:20.04 |
| tor8 | holler when you want to look, and I'll walk you through the build | 11:20.38 |
| Robin_Watts | paulgardiner: Your patch looks good, with one minor proviso. | 11:22.58 |
| | In get_populating_xref_entry... | 11:23.44 |
| | you run from 0 to num_xref_sections-1, ensuring that every one is >= num. | 11:24.11 |
| | xref ends up being set to &doc->xref_sections[i] for the last value of i that the loop ran for, which is num_xref_sections-1, as long as num_xref_sections >= 1 | 11:25.33 |
| | it's safe, but doesn't look terribly pretty. | 11:25.41 |
| | Also, in general, we don't need to check all the incremental sections from 0...n-1 | 11:26.06 |
| | Hold on, I've confused myself again. | 11:27.13 |
| paulgardiner | I was aware of the reliance on how the loop stopped: I put a comment in because it wasn't obvious. I could add an explict assignment | 11:27.26 |
| Robin_Watts | chrisl: tor8: paulgardiner still can't push to git, he gets an unpacker error. | 11:37.52 |
| | Do we need to add him to a group or something? | 11:38.00 |
| tor8 | Robin_Watts: he needs to be in the gs-pub group to push | 11:38.54 |
| Robin_Watts | paulgardiner: Try pushing again now ? | 11:49.05 |
| paulgardiner | Sorted | 11:49.34 |
| Robin_Watts | fab. | 11:49.41 |
| | tor8, paulgardiner: As tor commented the other day (and I'd forgotten until now), the pdf page loading changes the objects in the file. | 12:18.40 |
| tor8 | Robin_Watts: I'm working on that... | 12:19.05 |
| Robin_Watts | It 'flattens' the resources, so that every page object directly has the resources it needs. | 12:19.08 |
| | oh, ok. | 12:19.12 |
| tor8 | just got distracted by opengl after having banged my head bloody on ios this morning | 12:19.24 |
| Robin_Watts | cos my progressive loading stuff just ran into the same area. | 12:19.34 |
| tor8 | Robin_Watts: did you see zenikos comments on the pdf_obj changes? | 12:19.39 |
| Robin_Watts | I didn't. Let me look now. | 12:19.49 |
| paulgardiner | Hmmm. I seem to be loading pages without the move-to-incremental code being triggered. | 12:20.02 |
| tor8 | I don't think the overflow issue is very likely (it'll only happen if he loads 65k+ pdf_page objects, indirect references don't refcount their "target") | 12:20.17 |
| Robin_Watts | Maybe those files are already flattened? | 12:20.40 |
| paulgardiner | But I'm having problems when trying to do old-style saving with sweepobj updating the Length's of streams | 12:20.55 |
| | Maybe I should just turn off the feature while saving. | 12:21.40 |
| Robin_Watts | tor8: Where are his comments ? | 12:21.47 |
| tor8 | bug 694382 | 12:22.06 |
| Robin_Watts | paulgardiner: Oh, I see. As we save we rewrite the Lengths in the dicts, and that causes the objects to be moved? | 12:22.17 |
| paulgardiner | yep | 12:22.27 |
| Robin_Watts | Turning off the feature while saving seems reasonable :) | 12:22.38 |
| paulgardiner | Okay. I'll give that a go. | 12:22.52 |
| tor8 | rewriting the /Lengths is strictly speaking unneccessary | 12:22.52 |
| | but I hated how ofter the /Length was just pointing to an indirect object after the stream... | 12:23.07 |
| | old-style saving, is that the usual 'save everything' non-incremental mode? | 12:23.55 |
| paulgardiner | It's probably good to permit tidying during saving without triggering the move to incremental | 12:23.56 |
| | tor8: yeah. | 12:24.19 |
| tor8 | paulgardiner: how about a separate function / pass to clean up the lengths instead? | 12:24.30 |
| paulgardiner | tor8: possibly, but I can imagine other cases of little changes being convnient during saving | 12:25.12 |
| tor8 | which pdfclean would do, but not incremental (or other, even) saves | 12:25.13 |
| Robin_Watts | I should look into his comments. | 12:25.17 |
| | I think the refcounting is safe, as you say, but the others may be valid. | 12:25.37 |
| tor8 | Robin_Watts: the type3 one sounds like it could be trouble | 12:25.40 |
| | but we could just nuke the cache when closing documents and be done with it | 12:25.59 |
| paulgardiner | tor8: I'm seeing this happen only in sweepobj at present | 12:26.00 |
| | I'm hoping it's the reason for the blank docs I'm creating on save. :-) | 12:26.43 |
| Robin_Watts | tor8: Or nuke the entries in the glyph cache that match a given document on a document close at least. | 12:27.17 |
| paulgardiner | tor8, robin_watts: by the way, I may have missed something, but this looks to be working out very simply - much better than my case-by-case version. I feared that handling the general case could require more complication than case-by-case, but thankfullky it looks like I was wrong. | 12:28.07 |
| Robin_Watts | Q: What does the "B" in Benoit B. Mandelbrot stand for? | 12:29.22 |
| | A: Benoit B. Mandelbrot. | 12:29.33 |
| paulgardiner | :-) | 12:31.02 |
| Robin_Watts | There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors. | 12:36.35 |
| kens | I think I have a cunning solution to my problem :-) | 12:48.58 |
| paulgardiner | Hmmm, now I have pushing rights, I'd really better rename origin and paul to golden and origin before the obvious accident happens | 13:01.17 |
| Robin_Watts | paulgardiner: :) | 13:02.47 |
| kens | Hmm cluster run aborted, not a good sign | 13:15.09 |
| | crumbs, half the cluster is down O.O | 13:18.09 |
| | ah, and now its better | 13:18.29 |
| paulgardiner | tor8, robin_watts: the move-to-incremental patch is up on paul/master. Can't be sure I'm spotted everything that needed changing, but debug runs seem to show it triggering in the correct situations. I've built for Android and seem to be able to still old-style save annotation and form changes. I also have a cluster test queued | 13:21.09 |
| | BTW, the Android app crashes on save with or without these changes. Something we need to track down. | 13:21.40 |
| | kens: just after my first ever push - I hope that's coincidence. :-) | 13:25.48 |
| kens | paulgardiner : I'm baffled, the code I added shouls not have had this effect, and works with teh affected file locally :-( | 13:26.13 |
| | well, the couple I tried that were failing with timeouts | 13:26.26 |
| | So I'm kind of baffled | 13:26.37 |
| | I did a quick reformat of it and am trying again | 13:27.27 |
| mvrhel_laptop | How do I get Importance to show up in my list of bugs in bugzilla | 13:43.44 |
| Robin_Watts | Change Columns ? | 13:44.26 |
| mvrhel_laptop | oh yes | 13:44.31 |
| | just found it :) | 13:44.34 |
| | Not sure when it changed though | 13:44.43 |
| | I used to have it on there | 13:44.48 |
| Robin_Watts | tor8: So in our cluster testing, we only have 2 files that ever take refs >= 256 | 13:45.25 |
| kens | Hmm clusrter is happy this time it seems | 13:51.15 |
| Robin_Watts | tor8: And those are indeed a resource reference. | 14:03.17 |
| | Or at least one of them is, in the forms stuff. | 14:03.30 |
| | ok, both in the forms stuff. | 14:05.27 |
| paulgardiner | TTOTD: when enumerating an array in reverse order, *decrement* the index | 14:28.25 |
| Robin_Watts | TTOTD: When debugging through a pdf file, do not be surprised if the numbers fail to match up with the one you have in your editor if the editor contains a different file. | 14:31.39 |
| paulgardiner | :-) | 14:32.55 |
| kens | Weird, if I use abs() I get lots of timeouts, if I simply multiply by -1, I don't..... | 14:42.31 |
| tor8 | Robin_Watts: the refs>256 could be our resource dict page tree flattening, so those will be solved soon | 14:49.58 |
| Robin_Watts | This is in copy_resources, part of the forms thing. | 14:52.48 |
| | Paul goes looking for a /DR entry and copies entries from there, into the resources dictionary of the widget. | 14:54.06 |
| | In these two files, the resources themselves are all indirect refs. | 14:54.32 |
| | but the problem I'm seeing is with the keys of the dictionary, not the values. | 14:54.55 |
| | He runs through the dictionary, i =0 to len. Reads key = ith key. Checks to see if that key exists in the destination dictionary, and if not, writes the value in with that key. | 14:56.07 |
| | Hence the refcounts for the keys goes up. | 14:56.19 |
| | BUT... this code needs to be changed, I think. | 14:56.39 |
| | We can't be flattening the resources like this, because if we save a file after it's been loaded like this, it'll be different, right? | 14:57.11 |
| shobhit | Anyone available? | 14:58.54 |
| | I am trying to build the MuPDF and I am getting following error: | 14:59.47 |
| | C:/Android-NDK/android-ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld.exe: ./obj/local/armeabi-v7a/libmupdfcore.a(image.o): in function fz_decomp_image_from_stream:jni/../../../source/fitz/image.c:182: error: undefined reference to 'fz_unpack_tile | 14:59.50 |
| | Can anyone help me? | 15:00.01 |
| Robin_Watts | shobbit: hold on a mo. | 15:02.38 |
| | fz_unpack_tile is defined in fitz/draw-unpack.c | 15:03.14 |
| | shobbit: Are you building the latest version from git? | 15:03.53 |
| shobhit | yes | 15:03.57 |
| | Before everything | 15:04.12 |
| Robin_Watts | shobhit: Apologies for mistyping your name! | 15:04.36 |
| shobhit | I would like to tell you that I want to use MuPDF to read and parse the PDF in android | 15:04.44 |
| Robin_Watts | shobhit: OK. Your choices are either to comply with the GNU GPL license, or to become a commercial licensee. | 15:05.16 |
| shobhit | As I am developing an android application which will support the PDF annotations. | 15:05.23 |
| Robin_Watts | shobhit: OK. We are working on annotation support too. | 15:05.52 |
| | (slowly) | 15:05.55 |
| shobhit | I just saw that fz_unpack_title is defined in fitz/draw-unpack.c | 15:09.13 |
| | but now how should I continue? | 15:09.23 |
| | @Robin_Watts: Could you please copy and paste all your replies if you gave any sometime back? | 15:21.19 |
| | I got disconnected from the netwrork | 15:21.31 |
| Robin_Watts | shobhit: On phone, sorry. | 15:21.33 |
| shobhit | Just to summarize: I want to develop and android application which will help annotating the PDF files in android. Thus, I am using MuPDF to read and Parse the PDF files in android. I am trying to build it but I have encountered the following error: | 15:23.28 |
| | C:/Android-NDK/android-ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld.exe: ./obj/local/armeabi-v7a/libmupdfcore.a(image.o): in function fz_decomp_image_from_stream:jni/../../../source/fitz/image.c:182: error: undefined reference to 'fz_unpack_tile | 15:23.32 |
| | I got to know that fz_unpack_tile is defined in fitz/draw-unpack.c | 15:27.49 |
| | Now I am not sure of how to continue from here | 15:28.19 |
| | Can someone help me? | 15:28.26 |
| Robin_Watts | shobhit: Right, sorry, off phone now. | 15:28.33 |
| | For reference, this channel is logged. If you look in the topic line you'll see a link you can click on to check whether you missed stuff. | 15:29.05 |
| | paulgardiner did a build of the up to date android app this morning, and it worked fine. | 15:29.24 |
| | hence there should not be a problem with the sources as in git. | 15:29.44 |
| | Can you completely clean your dir, then rebuild and capture the build log. | 15:30.11 |
| | then post that somewhere we can look at please ? | 15:30.18 |
| kens2 | OK I'm off, night all | 16:16.30 |
| Robin_Watts | tor8: ping | 16:26.01 |
| tor8 | Robin_Watts: yeah. they'll get flattened, which we probably won't want. | 16:27.20 |
| Robin_Watts | tor8: It turns out that paulgardiner's flattening stuff only kicks in if we are synthesising appearance streams that don't exist. | 16:28.23 |
| | and arguably if we are synthesising appearance streams, then that *should* count as a difference when we save the file back. | 16:28.51 |
| | So I am not too concerned about the flattening code. I'm rather more interested in how we solve the refcounting problem. | 16:29.43 |
| | Suppose we have an array of 256x256 widgets on a page. | 16:30.06 |
| | We'd end up overflowing the refcount there. | 16:30.32 |
| | one possibility is that when we 'keep' an obj, we check for the refcount getting too large, and if it does, we clone the object and return the cloned one. | 16:31.16 |
| | That would mean we'd need to ensure that we always use the return value from pdf_keep_obj | 16:31.45 |
| tor8 | Robin_Watts: or we add 2 bytes to the pdf_obj struct :) | 16:32.38 |
| Robin_Watts | yeah. | 16:33.17 |
| | Well, it's 4 bytes, but... | 16:33.23 |
| | There are only 2 places in the code where we ignore the return code from pdf_keep_obj, and they could easily be fixed. | 16:40.30 |
| | I guess I'd be happy to go back to an int. It's probably the simplest all around. And even with the parent int that paulgardiner is adding now, we'd be no bigger than we were before. | 16:42.56 |
| | tor8, paulgardiner: Anyone going to dissent with me going back to an int? | 16:43.16 |
| tor8 | go for it | 16:43.22 |
| paulgardiner | int sounds good to me | 16:44.03 |
| Robin_Watts | I'm looking at changing the code from adding "Dirty" entries all over the place to using a flags word bit. | 16:47.25 |
| | and it occurs to me... are we sufficiently protected from multiple threads trying to access the same flags words at the same time? | 16:47.51 |
| | What guarantees do we currently have that only 1 thread is reading/writing Dirty at a time? | 16:48.10 |
| tor8 | yesterday, you said pdf_obj's belonged to a single context... | 16:48.40 |
| Robin_Watts | So I did! | 16:49.25 |
| | Well done. You were paying attention. Test passed. | 16:49.47 |
| | :) | 16:49.50 |
| tor8 | :) | 16:50.31 |
| | Robin_Watts: http://ghostscript.com/~tor/stuff/freeglut.zip has binaries for win32 that you can just unzip into thirdparty/ | 16:52.06 |
| Robin_Watts | Thanks. | 16:52.21 |
| tor8 | should work for MSVC too, if you set up the project | 16:52.24 |
| | there's both mingw .a and msvc .lib and .dll there | 16:52.41 |
| | for msysgit you need to run c:\msysgit\mingw\bin\make.exe rather than the default c:\msysgit\bin\make.exe | 16:54.14 |
| | the mingw make is version 3.81 and the default make is version 3.79 ... the 3.79 version is ancient and doesn't support half of the features we use in our makefiles | 16:54.52 |
| Robin_Watts | tor8: Do you have an ETA on the page loading changes? | 17:00.51 |
| tor8 | tomorrow. | 17:01.18 |
| Robin_Watts | Fab. My progressive work is blocked on that, I think. | 17:01.32 |
| tor8 | right. I'll make it top priority tomorrow morning then. | 17:01.47 |
| Robin_Watts | ta. | 17:05.24 |
| ray_laptop | tor8: robin_watts: paulgardiner: I closed bug 694376 as INVALID (with an explanation). Probably this guy was using an old iOS mupdf app that ignored annotations. | 17:06.44 |
| tor8 | ray_laptop: is he a customer? | 17:09.00 |
| | otherwise, we ought to remind him of the GPL terms and conditions (he mentioned developing an app for android) | 17:09.36 |
| Robin_Watts | tor8: Am doing that now. | 17:10.22 |
| tor8 | the iOS viewer he's talking about is most likely apple's built in pdf viewer. | 17:10.35 |
| ray_laptop | tor8: does it ignore annotations | 17:17.09 |
| | ? | 17:17.12 |
| tor8 | no idea. | 17:17.23 |
| Robin_Watts | tor8, paulgardiner: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=10dc3cad879c16b9da033941285080bd7519f75f | 17:17.47 |
| ray_laptop | I don't have an iphone. My wife has an ipod | 17:17.53 |
| tor8 | but it wouldn't surprise me if it either ignored them, or selectively ignored video annotations. | 17:17.54 |
| ray_laptop | I guess I could check, except I already closed the bug which deletes my motivation :-) | 17:18.28 |
| tor8 | Robin_Watts: do you really want to mix in the smear/clean fixes with zenikos fixes? | 17:20.02 |
| | the changes look fine | 17:20.26 |
| Robin_Watts | tor8: I guess not. Let me separate them. | 17:20.30 |
| paulgardiner | robin_watts: is that pdf_print_obj call intentionally left in? | 17:22.37 |
| Robin_Watts | paulgardiner: No, there were 2 cockups in there, that was one :) | 17:22.56 |
| tor8 | smear, or smudge? | 17:23.28 |
| Robin_Watts | tor8: either works for me. Smear is what happens to peoples good name when you dirty them in the press. | 17:24.32 |
| tor8 | smudge is what git uses for their filter combos (like when changing tabs/spaces) | 17:25.03 |
| Robin_Watts | Right. smudge implies taking something and making something that's almost the same, just a bit blurred. | 17:26.12 |
| | I could live with either. | 17:26.32 |
| tor8 | hm, the word order for dicts etc is to your preference, but for obj I'm not sure we're very consistent | 17:26.53 |
| Robin_Watts | yeah, I spotted that too. | 17:27.12 |
| tor8 | (pdf_clean_obj vs pdf_obj_clean) | 17:27.14 |
| Robin_Watts | How about I change them all, and then use pdf_obj_is_dirty/pdf_dirty_obj/pdf_clean_obj ? | 17:27.47 |
| | pdf_mark_obj/pdf_unmark_obj seems to be right by our scheme. | 17:31.15 |
| | pdf_obj_stash/pdf_obj_stashed or pdf_stash_obj/pdf_stashed_obj ? Neither seems really right. | 17:32.00 |
| tor8 | pdf_stash_obj / pdf_is_obj_stashed would sit best (not that I particularly like the second one) | 17:34.35 |
| | but I could live with pdf_obj being the exception to the rule | 17:34.53 |
| | so pdf_obj_stash / _stashed | 17:35.09 |
| | or pdf_obj_is_stashed | 17:35.13 |
| | to go with pdf_dict_xxx | 17:35.19 |
| | and pdf_array_xxx | 17:35.22 |
| Robin_Watts | pdf_stash_obj/pdf_is_obj_stashed doesn't sound right to me. It's not the object that's stashed. | 17:37.35 |
| | It's that we can stash a boolean in the object. | 17:37.48 |
| tor8 | pdf_flag_obj, pdf_get_obj_flag | 17:38.28 |
| Robin_Watts | That would be for the more general set/get flag bits ? | 17:38.54 |
| tor8 | no, just alternative name for stash | 17:39.08 |
| | but I liked stash | 17:39.11 |
| Robin_Watts | stash->flags would be a bad step, imho. | 17:40.02 |
| tor8 | pdf_obj_stash_bool / pdf_obj_stashed_bool | 17:41.01 |
| | or "get" | 17:41.07 |
| Robin_Watts | pdf_stash_in_object | 17:41.12 |
| | pdf_stash_in_obj | 17:41.15 |
| | pdf_retrieve_stash_from_obj ? | 17:41.27 |
| tor8 | pdf_obj_stash, pdf_obj_unstash | 17:43.54 |
| Robin_Watts | The operation does not take the stash out from the objec.t | 17:44.17 |
| tor8 | yeah, scratch that. | 17:44.28 |
| Robin_Watts | pdf_peek_obj_stash | 17:44.51 |
| | Maybe this is an indication that we need a better name. but I can't think of one. | 17:45.26 |
| tor8 | sleep on it! :) | 17:45.34 |
| | or take a shower (your hot water's been fixed I hope) | 17:45.46 |
| Robin_Watts | It has, thankfully. | 17:46.04 |
| | pdf_set_obj_memo, pdf_read_obj_memo ? | 17:46.18 |
| tor8 | pdf_set_obj_memo, pdf_obj_memo | 17:47.57 |
| Robin_Watts | ok, I like that. | 17:48.54 |
| | ok, 2 updated commits on robin/master then. | 17:54.46 |
| tor8 | Robin_Watts: s/pdf_dirty_object/pdf_dirty_obj/ | 19:04.12 |
| Robin_Watts | oops. ok. | 19:04.32 |
| | other than that? | 19:05.09 |
| | New version up. | 19:06.26 |
| henrys | phew bug 694341 - when multiple things are wrong things a bug can chew up a lot of time. | 21:21.32 |
| sebras | I have a pdf causing: | 22:57.27 |
| | WARNING in tgt_create tree->numnodes == 0, no tree created. | 22:57.31 |
| | WARNING: No incltree created. | 22:57.31 |
| | WARNING in tgt_create tree->numnodes == 0, no tree created. | 22:57.39 |
| | WARNING: No imsbtree created. | 22:57.40 |
| | is this expected? | 22:57.45 |
| | have neither checked the code nor the file. | 22:58.05 |
| | Forward 1 day (to 2013/06/28)>>> | |
IRC Logs