| | <<<Back 1 day (to 2016/07/07) | 20160708 |
| tor8 | Robin_Watts: in muraster.c, in drawpage() | 09:50.01 |
| | you create a list device and if GREY_FALLBACK a test device | 09:50.47 |
| | but you only run on the list device in the #else branch | 09:50.58 |
| | that looks confusing to me | 09:52.19 |
| | Robin_Watts: a big list of commits on tor/master for review | 10:07.39 |
| | I can squish a lot of the related ones into one commit for pushing, but I figured it's easier to review them this way | 10:08.01 |
| Robin_Watts | tor8: will look in just a mo. | 10:14.40 |
| | Everything up to the "slimming" commits looks good. | 10:21.53 |
| | The only worry with the slimming commits I have is that we might suddenly find that some operations are slower. | 10:22.13 |
| tor8 | Robin_Watts: some of them will be slower, most should be unaffected | 10:22.49 |
| Robin_Watts | Like, when we click on a page, and we run through the links etc to see if we've clicked on something, the link/annot bounding will now be slower. | 10:22.56 |
| tor8 | none of them are called more than at most a dozen times per page render | 10:22.58 |
| Robin_Watts | One possibility to fix that would be to amend pdf_dict objs with a function that gets called when they are changed. | 10:23.41 |
| tor8 | and now, when editing stuff, there's no risk of forgetting to keep the cached values in sync | 10:23.42 |
| | ugh. that way lies event callback chains and madness. | 10:23.59 |
| Robin_Watts | And that function would invalidate the associated struct. | 10:24.11 |
| | yes. | 10:24.13 |
| | And it would bloat pdf dicts. | 10:24.18 |
| | OK, let's skip that unless we find it's needed. | 10:24.30 |
| tor8 | links are currently not affected--they're preparsed and resolved at load time | 10:25.20 |
| | fixing links to be opaque so we can make them work with reflowable document is on my TODO list | 10:25.54 |
| Robin_Watts | close/drop - that's me gotta rewrite some docs then :) | 10:28.47 |
| tor8 | Robin_Watts: yeah, sorry. | 10:28.55 |
| Robin_Watts | No, I agree it makes sense :) | 10:29.05 |
| | If we have the convention that fz_drop_xxx is never allowed to throw, then we should possibly add some debug code in fz_drop etc to fz_try() and fz_catch() with an assert in it. | 10:30.59 |
| tor8 | yeah, that would be nice but I'm having difficulty seeing where/how to add it | 10:34.04 |
| Robin_Watts | fz_drop_imp ? | 10:36.42 |
| | Hmm, not so easy. | 10:36.56 |
| tor8 | that only does the reference counting bit | 10:37.00 |
| | the things that throw would happen afterwards | 10:37.06 |
| Robin_Watts | We could have a macro fz_drop_imp(ctx, blah, &blah->refs, dropblock); ? | 10:38.13 |
| tor8 | something else I read worries me a bit | 10:38.30 |
| Robin_Watts | not so keen on that. | 10:38.34 |
| tor8 | the java finalizer may run in a separate thread... | 10:38.38 |
| Robin_Watts | brb. | 10:39.08 |
| | OK, so the problem presumably then might be that a java object gets finalized on a new thread. | 10:45.36 |
| | which causes the native object to get dropped. | 10:45.47 |
| | When the JNI is called to drop the native object, we check to ensure we have a context for that thread. | 10:46.20 |
| | and if we don't have one, we make one , I think. | 10:46.31 |
| | take Device_finalize for example. | 10:47.41 |
| | we call get_context(env) in that. | 10:47.53 |
| tor8 | we should make doubly sure that all refcounting happens with the fz_drop_imp lock | 10:48.17 |
| Robin_Watts | So we might make a new context just to be able to do the drop. | 10:48.26 |
| tor8 | and then we would be safe, because nobody else can be holding a pointer to the data if we actually end up freeing it | 10:48.38 |
| Robin_Watts | tor8: All refcounting MUST be protected by that lock already. | 10:49.00 |
| | (that is to say, SHOULD, it's not automatically checked anywhere) | 10:49.24 |
| tor8 | I'd better go round up the criminals then :) | 10:49.33 |
| Robin_Watts | I think the design is safe. | 10:49.34 |
| tor8 | I'll do that after lunch. | 10:50.09 |
| | so you're happy with the commits on tor/master? | 10:50.21 |
| Robin_Watts | I am. | 10:50.26 |
| tor8 | squish or annoy the cluster? | 10:50.44 |
| Robin_Watts | I'm good either way. They don't take that long. | 10:51.01 |
| tor8 | then I'll keep them unsquished | 10:51.15 |
| | easier to see what changes and why with smaller commits | 10:51.27 |
| olspookishmagus | hello, I'm trying to use gs's pdfwrite and I get: | 11:41.43 |
| | -g must be followed by <width>x<height> | 11:41.46 |
| | - those numbers are in PIXELS or in POINTS? | 11:42.00 |
| | - those numbers need to be integers or decimals are OK? | 11:42.19 |
| Robin_Watts | According to the docs: | 11:46.08 |
| | -g<width>x<height> is equivalent to -dDEVICEWIDTH=<width> -dDEVICEWIDTH=<height> | 11:46.41 |
| | -d sets integers, so they are integers. | 11:46.49 |
| | Also according to the docs there are -dDEVICEWIDTHPOINTS=<width> -dDEVICEHEIGHTPOINTS=<height> | 11:47.32 |
| | so that would suggest that -dDEVICEWIDTH and -dDEVICEHEIGHT take pixels. | 11:47.53 |
| | And a quick test does indeed confirm that they are pixels. | 11:49.01 |
| | (I was testing png24m rather than pdfwrite though, so YMMV) | 11:50.05 |
| olspookishmagus | thanks Robin_Watts | 11:50.58 |
| Robin_Watts | Right, they are pixels in pdfwrite. The default pdfwrite resolution is 720dpi. | 11:51.13 |
| olspookishmagus | so let's hope my results of rounding decimals and passing them to pdfwrite will yield OK results | 11:51.49 |
| | what I'm trying to to is to have PDF scans of A4 landscape pages converted to 2x A5 portrait pages | 11:52.50 |
| kens | This should be a starting poitn for such a thing: | 11:56.05 |
| | http://stackoverflow.com/questions/22153661/split-large-pdf-image-into-multiple-pages-using-pstools | 11:56.05 |
| olspookishmagus | so I guess I will also have to find the source's DPI for accurate conversions between Pixels and Points | 11:56.15 |
| | I'm on the track with this: https://superuser.com/a/192293 but let me check your link | 11:56.45 |
| kens | I've a feeling there was a bug in that version of the program which I later fixed.... | 11:58.15 |
| tor8 | Robin_Watts: in fitz/store.c, evict() | 11:58.46 |
| kens | Fixed version of -df_slice.ps can be found attached to this bug report: | 11:59.22 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=692170 | 11:59.22 |
| tor8 | Robin_Watts: nvm. | 11:59.41 |
| Robin_Watts | olspookishmagus: mutool poster :) | 12:00.15 |
| | mutool poster -x 2 in.pdf out.pdf | 12:01.07 |
| | lossless, and fast. | 12:01.26 |
| olspookishmagus | oh great, let me see if that's available under a cygwin env | 12:12.52 |
| Robin_Watts | tor8: "Slim pdf_annot struct: remove cached matrix field." done broke stuff :( | 12:15.52 |
| tor8 | Robin_Watts: oh bollocks :( | 12:16.00 |
| | I thought I tested that with all my annotation files :/ | 12:16.13 |
| Robin_Watts | but not on the cluster? | 12:16.25 |
| tor8 | Robin_Watts: in stream-open.c there are calls to Memento_takeRef and Memento_dropRef in fz_keep_stream/fz_drop_stream that I haven't seen anywhere else | 12:17.00 |
| | for your debugging use? | 12:17.04 |
| Robin_Watts | tor8: No, ideally they should be used everywhere. | 12:18.09 |
| | but I hadn't got that far. | 12:18.18 |
| tor8 | Robin_Watts: put them in drop_imp etc? | 12:18.27 |
| | Robin_Watts: hm. roll back the git to before it broke? | 12:18.38 |
| Robin_Watts | It means that blocks keep a record of when they are malloced/taken/dropped/ etc, so you can see the history. | 12:18.45 |
| | tor8: Sounds good to me. | 12:18.49 |
| | If you force push, I'll fix the cluster. | 12:18.57 |
| olspookishmagus | hope you won't mind me lurking around :D thanks for all the tips/help | 12:20.54 |
| tor8 | Robin_Watts: force pushed. | 12:21.30 |
| kens | olspookishmagus : anyone's welcome to lurk..... | 12:21.52 |
| Robin_Watts | tor8: hopefully cluster should be back to normal now. | 12:22.32 |
| Robin_Watts | foods. | 12:22.49 |
| tor8 | Robin_Watts: huh. that's funny ... we're trying to draw annots without an appearance stream xobject. | 12:34.04 |
| olspookishmagus | Robin_Watts: you know of a switch that mutool will put each page to its own file? | 12:35.29 |
| kens | out%d.pdf ? | 12:35.50 |
| kens | is only guessing | 12:35.58 |
| tor8 | olspookishmagus: no such switch. | 12:36.01 |
| kens | Can you burst a PDF file afterwards ? | 12:36.19 |
| tor8 | olspookishmagus: you'll need to use shell magic like for P in $(seq 1 50); do mutool poster in.pdf out$P.pdf $P or something similar | 12:37.09 |
| | kens: that would probably be easier, yes. loop over the pages and invoke mutool clean to create a new file for each page | 12:37.41 |
| olspookishmagus | let me check on that | 12:40.54 |
| kens | suspects Robin killed my cluster test :-) | 12:40.56 |
| kens | runs it again.... | 12:41.15 |
| olspookishmagus | thanks for your suggestion tor8 | 13:09.01 |
| Robin_Watts | kens: Not intentionally, no. | 13:33.06 |
| kens | Its OK I reran it | 13:33.16 |
| | I htink it was queued in the muPDF ones | 13:33.47 |
| Robin_Watts | kens: Yeah, I thought I deleted the mupdf ones and left that one, but I may have messed up. | 14:14.02 |
| kens | not a problem | 14:14.10 |
| tor8 | Robin_Watts: fix up on tor/master | 15:14.00 |
| Robin_Watts | I can't immediately see the difference, but it looks plausible to me. | 15:18.56 |
| | Have you cluster tested? | 15:19.01 |
| tor8 | Robin_Watts: I just added a test that annot->ap actually exists | 15:20.00 |
| | and a warning, which ought to prompt us to implement the missing annotation appearance synthesis :) | 15:20.23 |
| Robin_Watts | Would seem sensible to cluster test the final commit before pushing. | 15:20.31 |
| tor8 | I have | 15:20.35 |
| Robin_Watts | Then push away! | 15:20.45 |
| tor8 | will just squish down the fix and push | 15:20.47 |
| | Robin_Watts: did you check the keep_imp and drop_imp fix too? | 15:21.11 |
| Robin_Watts | Yes, looks good too. | 15:22.59 |
| tor8 | Robin_Watts: fab, thanks. | 15:23.11 |
| Robin_Watts | tor8: Did you forget to add resources/fonts/sil/SourceHanSansXX-Regular.otf? | 16:02.43 |
| | tor8, mvrhel_laptop, fredross-perry, sebras(for the logs): Anyone up for some trivial MuPDF reviews? | 16:20.37 |
| fredross-perry | sure | 16:20.48 |
| | now? | 16:20.56 |
| Robin_Watts | git is being slow... | 16:21.00 |
| | Ok, there now. | 16:21.47 |
| fredross-perry | looking ... | 16:31.10 |
| | seems OK to me. Will "Can't ..." be OK (single quote inside double quote) | 16:34.47 |
| Robin_Watts | Yes, that's fine. | 16:42.08 |
| | The single quote is why I needed to add the double quotes :) | 16:42.25 |
| | fredross-perry: Thanks. | 16:45.26 |
| fredross-perry | np | 16:45.36 |
| sebras | Robin_Watts: sorry for breaking the win build. I suppose I did the same thing for luratech and jpegxr though. | 16:49.34 |
| Robin_Watts | sebras: No problem, I'm used to that :) | 16:50.09 |
| | The font stuff had me scratching my head for a bit :) | 16:50.23 |
| | Did you know that recently Taiwan "accidentally" launched a missile against China? | 16:50.50 |
| | But it's OK, cos the missile was a bit crap and so fell in the sea. | 16:51.10 |
| | http://edition.cnn.com/2016/07/01/asia/taiwan-fires-missile-on-china/index.html | 16:51.44 |
| sebras | Robin_Watts: yeah I read about it. | 16:53.21 |
| | taiwan news mentioned it and english news mentioned that china questioned whether it actually was accidental. | 16:53.46 |
| | given how things happen here, I wouldn't be surprised that if it was accidental though. | 16:54.02 |
| mvrhel_laptop | Robin_Watts: sorry I missed you call for review. I am above my eyeballs in overprint/transparency stuff and patterns just got added to the mix | 16:54.39 |
| | s/you/your/ | 16:54.44 |
| Robin_Watts | mvrhel_laptop: No worries, fredross-perry stepped up. | 16:54.52 |
| fredross-perry | and then scurried away | 16:55.23 |
| Robin_Watts | 2 line review for anyone up for it: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=16c8afb8322e33a5177251cb56688406c1ec02e5 | 16:58.00 |
| tor8 | Robin_Watts: d'oh! typo. should be han, not sil. | 17:43.17 |
| | Robin_Watts: LGTM | 17:44.13 |
| Robin_Watts | tor8: Ta. | 17:46.04 |
| fredross-perry | tor8, robin - what's the right way, using the new JNI, to run page contents and annotations separately? | 18:04.28 |
| Robin_Watts | looking... | 18:04.37 |
| fredross-perry | Robin - I patterned what I am doing after your jni4, but it's not working as I expected. Rebuilding jni4 now to see if that actually worked. | 18:06.28 |
| Robin_Watts | ok, so in C, I'd do it by calling fz_run_page_contents then I'd call fz_run_annot on each annot in turn, as returned by fz_first_annot then fz_next_annot. | 18:06.57 |
| | fz_run_page_contents should be directly equivalent in JNI. | 18:07.26 |
| | Annotations are different, because we have tried to be 'more java-like'. | 18:08.29 |
| | Page.getAnnotations() should return an array of annotations. | 18:08.46 |
| fredross-perry | Oh, and then I just run each one in turn? | 18:09.04 |
| Robin_Watts | and then you can run each one in turn. | 18:09.08 |
| | Yes. | 18:09.10 |
| fredross-perry | I'll try that. | 18:09.22 |
| Robin_Watts | If that doesn't work, then let me know - it's possible the JNI is screwed up. | 18:09.37 |
| fredross-perry | ok | 18:11.45 |
| | getting a crash in Annotation.run, so investigating that. | 18:17.05 |
| rayjj | I had an Asus tablet that died (< 6 mo old). Asus was pretty good about getting me an RMA, but since the unit doesn't show a S/N anywhere (apparently it was on the box that I threw away) it got "lost" for 7 business days (13 calendar days because of weekends and July 4th). | 21:26.23 |
| | There responsiveness is abysmal -- they won't even check their system until 48 hrs after the carrier says it has been delivered, then when they couldn't find it easily, they just said "check with the carrier". Except due to my personal downtime, that got delayed as well | 21:28.33 |
| | They told me Wed that it had actually been received 6/23 (as the carrier said), but because I didn't have the s/n they couldn't put it in their system. Finally, today 7/8 it shows as having been received 7/7 (not 6/23) -- probably so they don't look bad on their internal reports | 21:30.29 |
| | basically, they suck | 21:30.42 |
| | it's not like the tablet was actually damaged or dropped. IMHO, for a $99 tablet they should have sent me a refurbed or new one as soon as I provided the tracking info that said it was delivered | 21:32.11 |
| | my daughter has an Asus 13" notebook -- I have my fingers crossed | 21:32.57 |
| | mvrhel_laptop: for the logs, I'm running a test to see what files will be affected by the change to push, change BM, then pop. For now I just test the condition and do something "invalid" so the difference will show | 22:42.16 |
| | mvrhel_laptop: you can look at my regression run to see the "detection" logic http://ghostscript.com/regression/cgi-bin/clustermonitor.cgi?report=ray | 22:44.02 |
| | mvrhel_laptop: looks like 7 files are affected. (one is Altona_Technical_v20_x4.pdf) | 22:45.55 |
| mvrhel_laptop | rayjj; what does the bmpcmp look? | 22:46.43 |
| rayjj | mvrhel_laptop: probably garbage because in order to force a difference I set the blendmode to /BogusBM :-) | 22:47.23 |
| mvrhel_laptop | ah | 22:47.30 |
| | ok | 22:47.31 |
| | need to run an errand | 22:47.54 |
| | bbiab | 22:47.56 |
| rayjj | mvrhel_laptop: if it is a fill, and the 'op' is false (overprint of for other than stroking) will doing the begin/ BM=CompatibleOverprint/end hurt ? | 22:50.34 |
| | mvrhel_laptop: I just want to know how "picky" I have to be about doing the deed | 22:51.45 |
| Robin_Watts | and I have a reply from mq. | 23:11.27 |
| | Did that make it to tech? | 23:11.40 |
| | (I'm not sure that tech lets anyone else post to it) | 23:11.58 |
| | Bah, wrong group, swapping to private. | 23:12.26 |
| rayjj | he must not have cc'ed support or tech | 23:13.25 |
| | Forward 1 day (to 2016/07/09)>>> | |
IRC Logs