| | <<<Back 1 day (to 2017/07/05) | 20170706 |
| tapman | Hi all, a question about PDF format, when I open a PDF, it doesn't show the first page of the file, is there something in the PDF file that say which one is the first page ? | 09:27.32 |
| Robin_Watts | tapman: Yeah, there is an "initial view" setting or something. Not all viewers honour it. | 09:58.29 |
| | (IIRC) | 09:58.34 |
| kens | Not all viewers respect it, Ghostscript doesn't for instance | 09:58.57 |
| | ViewerPreferences dicitonary in the Catalog it looks like | 10:01.07 |
| | Hmm, that seems too complex | 10:02.56 |
| tapman | ok, thanks, is there a tool to reset that ? | 10:03.25 |
| kens | Umm, no idea | 10:03.39 |
| tapman | open and save doesn't work | 10:03.49 |
| kens | but actually that looks like its too complex | 10:03.50 |
| | You would have to edit the PDF file, which has implications | 10:04.07 |
| | For one, if its signed, it would break the signing | 10:04.15 |
| | Looks like it could be the OpenAction in the Catalog dictionary | 10:05.34 |
| | So you could overwrite that with ahite space, that would do it | 10:06.10 |
| | with the caveat above | 10:06.20 |
| tapman | @kens with an Hex Editor ?? | 10:07.08 |
| kens | Absolutely, you must use an editor which does not alter line endings | 10:07.44 |
| | Or anything else for that matter :-) | 10:07.58 |
| tapman | ok, thanks | 10:09.15 |
| Robin_Watts | tor8: ping | 12:03.49 |
| | tor8: So I have to add some more complexity to the DeviceN colorspaces - specifically, I need to be able to get the colorant names etc from the draw device. | 12:04.31 |
| | Currently the devicen internals are pdf specific. | 12:04.43 |
| | In order for the draw device to use them I need them to be fz level things. | 12:05.01 |
| | But some of the internals are pdf_function things. | 12:05.28 |
| | so I'm trying something whereby part of the devicen internals will be exposed at the fz level (currently just the names), and the function stuff all remains hidden at the pdf level. | 12:06.15 |
| tor8 | Robin_Watts: const char *fz_color_component_name(ctx, cs, idx)? | 12:11.52 |
| | and expose that for all colorspaces | 12:12.26 |
| Robin_Watts | tor8: yeah, I was thinking that I'd have int fz_colorspace_devicen_n to return 0 if it's not devicen, and n if it is. | 12:12.46 |
| | separations would return 1. | 12:12.54 |
| | then fz_colorspace_component_name to take 0...n-1 and give you the name. | 12:13.23 |
| tor8 | yeah, that should work, I think | 12:13.26 |
| Robin_Watts | cool. will keep working. | 12:13.42 |
| tor8 | otherwise, maybe just trigger on the fz_is_colorspace_device_n, and have all colorspaces support reporting names | 12:13.56 |
| | so fz_colorspace_component_name(ctx, fz_device_rgb(), 1) would return "Green" | 12:14.19 |
| Robin_Watts | tor8: could do... | 12:14.32 |
| tor8 | dunno if that level of symmetry would be helpful | 12:14.41 |
| | but it would lessen the need for special casing, in the best case | 12:15.02 |
| Robin_Watts | tor8: Possibly might be with the NChannel madness in the PDF spec. | 12:15.04 |
| | I like the symettry of that, anyway. | 12:16.41 |
| | or symmetry, whatever. | 12:16.57 |
| sebras | Robin_Watts: when adding a new portfolio entry we look for the first unused O number and use that. | 13:13.05 |
| | later we renumber the entries in doc->portfolio. | 13:13.14 |
| | why is that done? | 13:13.21 |
| | or perhaps better: how does the renumbering improve things? | 13:13.35 |
| Robin_Watts | I dunno. | 13:13.41 |
| | Does the renumbering happen on deletion? | 13:13.57 |
| sebras | no, not that I can find. | 13:14.06 |
| | if it did then I'd see the use. | 13:14.12 |
| Robin_Watts | no idea then. | 13:14.14 |
| sebras | ok. :) | 13:14.22 |
| | Robin_Watts: btw, you mentioned having comments on the top commit on sebras/master last night? | 14:07.22 |
| Robin_Watts | not last night, but yes :) | 14:07.39 |
| sebras | last sleep cycle? | 14:07.58 |
| | the sleep cycle before that? | 14:08.05 |
| | tomorrows sleep cycle? I get confused. :) | 14:08.12 |
| Robin_Watts | I'm trying to find the relavent commit now. | 14:09.26 |
| | Have you addressed the other comments? | 14:09.36 |
| sebras | 640a0036e I think. | 14:09.45 |
| Robin_Watts | http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=commitdiff;h=85fe0926863eb53c8786648d54186543a1ccf4c3 still looks wrong. | 14:09.48 |
| sebras | I think so but I haven't pushed it yet. | 14:09.52 |
| | ok, I just updated sebras/master with hopefully corrected patches. | 14:10.28 |
| Robin_Watts | ok, right. | 14:11.16 |
| | So after that commit, the end of that function looks like: | 14:11.35 |
| | try { tok = ... } fz_catch(ctx) {drop, rethrow} skip: try { ... } fz_catch { drop, rethrow} | 14:12.44 |
| sebras | right. | 14:13.02 |
| Robin_Watts | i.e. the catch blocks are the same. | 14:13.10 |
| sebras | yeah I know. | 14:13.15 |
| | is it legal to jump into a fz_try? | 14:13.23 |
| Robin_Watts | And the sole point for coming out of the try and back in again, is to accomodate the skip: | 14:13.24 |
| | We can't jump into a try. | 14:13.30 |
| | but we could do something like: | 14:13.43 |
| sebras | right, that follows my thinking. | 14:13.52 |
| Robin_Watts | skipping = 0; if (0) { skip: skipping = 1; } try { if (!skipping) { tok = ... } ..... } catch { drop, rethrow } | 14:14.46 |
| | possibly with some renaming of skipping to "read_next_token" or something to make it clearer. | 14:16.38 |
| sebras | I wish I could conjure up another way to do this. | 14:23.31 |
| | Robin_Watts: besides this patch on sebras/master, how do you feel about the others? | 14:24.54 |
| | the js one is a patch I gave to tor8. | 14:25.04 |
| | tor8: mujs:sebras/master has a single patch. LGTY? | 14:25.18 |
| Robin_Watts | sebras: looking. | 14:25.28 |
| | second to last one... | 14:27.22 |
| | We've gone from pdf_update_object/pdf_drop_object in the non exception case to just pdf_update_object. | 14:27.46 |
| | should you be using an fz_always there? | 14:27.59 |
| | So, all but the last 2 lgtm. | 14:28.35 |
| sebras | Robin_Watts: ok, both have been fixed. | 14:31.19 |
| | Robin_Watts: I opted to ignore the skip label all together since it didn't appear to be necessary. | 14:32.46 |
| Robin_Watts | They both look nicer now. lgtm. | 14:33.35 |
| | Thanks. | 14:33.40 |
| sebras | Robin_Watts: yey! :) | 14:34.33 |
| tor8 | avih: I'm leaving soon, but I've cooked up a new variant of Number.prototype.toString(radix) on tor/master if you'd care to have a poke at it | 14:48.13 |
| | using integer math, so not going to have the weird floating point rounding issues with repeatedly multiplying with the radix | 14:48.37 |
| avih | tor8: did you find it more accurate than previous attempts? i think the double approach is as good (enough) as chrome.firefox as far as precision goes. | 14:50.09 |
| tor8 | this version is limited to using 32 bits of the mantissa, if we were to use uint64_t we could use all the bits (but still have rounding issues when scaling by the radix to fit an integer) | 14:50.20 |
| | the rounding with 64 bit integers is closer than just using double math, but it's hard to tell | 14:50.45 |
| avih | well.. with the double multiplied by radix you get at least ~48 bits accuracy (53 is the mantissa but you can lose up to 4-5 bits when cropping base 36 for instance) | 14:53.02 |
| | i'll try it, sure, but i really think it should not be less accurate than what double allows. so i'd say it'd be nicer if it used 64 bits ints. | 14:54.02 |
| | tor8: do you claim to comply with c99? c89? ansi c? if c99 then 64 bits ints are standardized | 14:54.30 |
| tor8 | the subset of C99 that works with MSVC 2005 | 14:57.31 |
| avih | 2005? | 14:58.00 |
| tor8 | yeah. it's ancient, but it's also the only version that still builds executables able to target win2k | 14:58.24 |
| | which is what we use for MuPDF | 14:58.34 |
| | use for MuPDF builds on windows | 14:58.59 |
| avih | also, you could move the 2-36 check to after the ==10 check, as it's by far the more common case so why nor save a test | 14:59.15 |
| | so, surely for msvc 2005 there are 64 bits ints, so just typedef them to int64_t or whatever you need? | 15:00.59 |
| | 32 bits for fraction + exponent range is really not fun | 15:01.45 |
| | tor8: not sure what's gained with "integer arithmetic" TBH. the only non integer arithmetic which happens with the double calculation is multiplying it by radix, which is an int, so you don't lose precision buts with that. | 15:04.09 |
| | bits* | 15:04.27 |
| tor8 | gotta go, back in a couple of hours | 15:05.15 |
| avih | tor8: anyway, i still think this is better, and simpler, and less error prone: https://0x0.st/00s.txt | 15:05.55 |
| | (it's your initial patch after i posted my patch, fixed to handle the cases i commented to you about) | 15:07.49 |
| sebras | Robin_Watts: another patch on sebras/master if you are available. | 15:56.11 |
| Robin_Watts | sebras: Urm... | 15:56.47 |
| | Oh ,before the fz_try, not the fz_var. gotcha. | 15:57.30 |
| | yeah, lgtm. | 15:57.35 |
| | Forward 1 day (to 2017/07/07)>>> | |
Log of #mupdf at irc.freenode.net.