| | <<<Back 1 day (to 2012/12/18) | 2012/12/19 |
| Robin_Watts | tor8: The type3 font one is evidently still broken. 43 SEGVS that I'll track down tomorrow. | 01:00.21 |
| | Morning tor8 | 10:26.47 |
| | Loads of reviews, I'm afraid. | 10:26.52 |
| | The type3 one has a problem I'm looking at now. | 10:27.16 |
| tor8 | Robin_Watts: yeah, I saw your message about segfaults :( | 10:27.42 |
| | oh boy, lots of reviews indeed! sebras has been busy too. | 10:28.17 |
| | oh no, I can't even read the output of git logg properly :( | 10:28.41 |
| Robin_Watts | You still full of cold? | 10:31.48 |
| tor8 | on the tail end, but yes :( | 10:42.10 |
| | and as such, sleep deprived :( | 10:42.27 |
| Robin_Watts | I highly recommend "Contac" - dunno if you can get that in .se | 10:49.54 |
| tor8 | Robin_Watts: Bug 693503: Fix potential SEGV in bitmap scalers. | 12:13.49 |
| | what you've written is (as I read it) if (w >= -1 && w <= 1) w = -1; | 12:14.16 |
| | do you have a minus sign too many? | 12:14.32 |
| | Robin_Watts: The type3 font stuff -- does it handle recursion and mutual recursion (i.e. a glyph that references itself, not just another glyph in the same font). Not sure that we catch that case in the interpreter with render_direct. | 12:18.20 |
| | s/Flatten all type3 glyphs/Flatten all type3 glyph display lists/ -- I misread that first thinking you'd turned *all* type3 text into render_direct :) | 12:19.17 |
| | Robin_Watts: device draw stack error swallowing looks good, but don't count on me catching subtle bugs today... | 12:24.10 |
| Robin_Watts | tor8: back. | 12:25.10 |
| | I probably have a - sign to many. will fix. | 12:25.23 |
| | I believe it does cope with recursion and mutual recursion. | 12:25.59 |
| | In render_direct we render from the charprocs each time. | 12:27.06 |
| | So in the interpreter, if we hit a type 3, we load all the char procs, then publish the font, then prepare the glyphs to make the display lists. | 12:27.41 |
| | If in the course of making the display lists we hit another type 3 glyph from the same font (the recursive case), we then render_direct and hence run the charprocs for that glyph. | 12:28.43 |
| | So we're safe (although potential unbounded infinite recursion may be an issue still) | 12:29.12 |
| tor8 | yeah, the nested prevents the display list from keeping the type3 font reference | 12:29.50 |
| | but not the infinite recursion | 12:29.56 |
| Robin_Watts | If in the course of making the display list we hit another type 3 font, we'll load, publish and then prepare the glyphs on that. If that comes back to the original font, we are again fine due to the render_directness. | 12:30.22 |
| | So, we have the infinite recursion to solve. | 12:30.31 |
| | Perhaps we should have nested be a count? | 12:31.08 |
| tor8 | Robin_Watts: interaction with XObjects? | 12:31.20 |
| Robin_Watts | That would solve the pathological, "not infinite but deep" case which might cause stack overflows. | 12:31.38 |
| | I have not considered any such interaction. What did you have in mind? | 12:31.55 |
| tor8 | a type3 glyph that calls an xobject form would reset the nested flag | 12:32.00 |
| Robin_Watts | tor8: Ah. I'll look at that, good catch, thanks. | 12:32.21 |
| tor8 | (depending on how we call the interpreter for it, it may be that we just reuse the same csi in which case there's nothing to worry about) | 12:33.11 |
| Robin_Watts | tor8: We do indeed reuse the same csi. | 12:47.34 |
| | So I've fixed the stray -1. | 12:47.43 |
| | and I've reworded the type3 commit title. | 12:48.23 |
| | I have 1 file that's changed, and the infinite recursion thing to fix. | 12:48.47 |
| | tor8: oh, what a git. tests/pdf/scn-in-type3font.pdf | 13:17.19 |
| | It has a type 3 glyph from (font 2) inside another type3 glyph (from font 1). | 13:17.56 |
| | Except the glyphs from font 1 are d0 ones, and the ones from font2 are d1 ones. | 13:18.14 |
| tor8 | eheheh | 14:15.06 |
| | Robin_Watts: ^ | 14:15.11 |
| Robin_Watts | Thanks elmer. | 14:15.27 |
| | No, sorry, eheheh was Mr Magoo, right? | 14:15.44 |
| | tor8: OK, I think I have something that works for the type3. The plumbing for the nested depth was a bit more wide ranging that I would have liked. | 14:25.02 |
| | and I note that we can load fonts in the forms stuff. | 14:25.17 |
| | which means form stuff may hit the file, so there may be threading implications for it. | 14:25.38 |
| | but that's for another day. | 14:25.44 |
| tor8 | Robin_Watts: looks like you've forgotten to push or pushed the wrong commits | 14:38.34 |
| | still -1 and old wording | 14:38.40 |
| Robin_Watts | sorry, I may have forgotten to push. | 14:43.05 |
| | try now. | 14:44.22 |
| | tor8: And the type3 stuff is good to go. 2 files show differences, but a bmpcmp reveals them to be rounding differences. | 15:05.43 |
| tor8 | Robin_Watts: you naughty! you try to sneak in camelCase! | 15:15.13 |
| Robin_Watts | nestedDepth ? | 15:15.40 |
| | should it be nested_depth ? | 15:15.44 |
| tor8 | it should. | 15:15.48 |
| Robin_Watts | Will fix. | 15:15.54 |
| tor8 | I'm thinking there may be a way to not spread it so far and wide | 15:16.03 |
| | have another flag in the t3 structs to say "is_processing_now_so_don't_recurse_past_me" but that runs into multithreading issues I guess | 15:16.44 |
| Robin_Watts | tor8: That would be fine. | 15:18.16 |
| | because we only process t3 stuff on interpretation. | 15:18.29 |
| | and interpretation hits the file. | 15:18.33 |
| | hence we can't be doing that in multiple threads. | 15:18.41 |
| | Would you like me to have a go at that way of working? | 15:22.46 |
| tor8 | yes please :) | 15:23.22 |
| Robin_Watts | OK, camelCase has gone (and update pushed to robin/master for safekeeping) | 15:24.05 |
| | Hmm. Moving to use flags gives us no protection against extreme recursion. | 15:25.19 |
| | Imagine a font where glyph 1 depends on glyph 2 which depends on 3 etc. | 15:25.31 |
| | That will blow the stack. | 15:25.41 |
| tor8 | Robin_Watts: lots of things can blow the stack that way | 15:26.38 |
| Robin_Watts | and we should fix them all. | 15:26.50 |
| tor8 | Robin_Watts: but infinite recursion loops are the main problem. | 15:27.04 |
| | Robin_Watts: rarely a problem on linux (and macosx) ... I only see stack overflow crashes on windows | 15:27.34 |
| Robin_Watts | Hmm. And if I lose the nesting level, the d1 in d0 stuff stops working. | 15:30.55 |
| tor8 | Robin_Watts: arguably that shouldn't work anyway | 15:31.15 |
| Robin_Watts | I could just hide the nesting level in the doc. | 15:31.24 |
| | Well, acrobat and us both agree on it currently. | 15:31.37 |
| tor8 | what does acrobat do with uncolored fonts using colored fonts in their glyphs? | 15:31.50 |
| Robin_Watts | tor8: greyscales the color ones I think. | 15:32.19 |
| tor8 | (either way I can't say I feel strongly on preserving any kind of behaviour for that odd case) | 15:32.27 |
| Robin_Watts | Given we only ever do this single threaded, putting nested_depth in the doc is fine. | 15:33.29 |
| | and gives us the best of all worlds, I think. | 15:33.40 |
| tor8 | Robin_Watts: I don't like that solution at all | 15:34.02 |
| | in the doc it'll get used in a multi-threaded environment as well. having it there is just confusing, I think. | 15:34.47 |
| Robin_Watts | fetches dogs/runs ot post office. ack in 5 mins. | 15:36.19 |
| paulgardiner | Robin_Watts: I've made the file picker rememer it's postion in directories as requested. Commit is on paulg/master | 15:37.36 |
| sebras | paulgardiner: yey, the picker supports directories. now we can try to open /dev/exynos-mem! :) | 15:43.04 |
| paulgardiner | Only if you can rename it to have a .pdf extension, I'm afraid. :-) | 15:44.35 |
| Robin_Watts | paulgardiner: Ta. | 15:59.55 |
| | tor8: It won't get used in a multi-threaded environment. | 16:00.17 |
| | I agree it's not ideal, but I'm really loathe to open us up to more malicious files than we need to. | 16:00.53 |
| tor8 | then keep the nested_depth argument | 16:01.43 |
| Robin_Watts | I think that's the best approach for now. | 16:04.31 |
| | If we can think of a neater solution, we can amend it later. | 16:04.44 |
| | so, are you happy with the reviews as they are on robin/master now ? | 16:07.24 |
| tor8 | yes. *nod* and all that. | 16:10.51 |
| Robin_Watts | Thanks. | 16:10.57 |
| | paulgardiner: commit looks plausible to me. I'll push it in a mo. | 16:18.03 |
| | paulgardiner: pushed (along with all of my stuff). | 16:45.27 |
| paulgardiner | Brilliant. Thanks | 16:45.53 |
| kens | Night all | 17:16.03 |
| Robin_Watts | oh, marvellous a SEGV in freetype. | 17:18.55 |
| mvrhel_laptop | this file in Bug693480 takes forever to run in debug mode.... | 19:17.46 |
| Robin_Watts | mvrhel_laptop: Use Memento, and run it under valgrind. Then you can stop early for Xmas. | 19:19.55 |
| mvrhel_laptop | that is an idea | 19:20.10 |
| sebras | paulgardiner: ping? | 21:11.40 |
| | tor8: you here? | 21:21.57 |
| | ok anyway -- since 8068b7b there is a dirty flag being set when repairing documents. this flag is checked by fz_has_unsaved_changes | 21:25.10 |
| | () which was added in the same commit. | 21:25.18 |
| | in commit 60a541f saving of form data in the android app was added which uses fz_has_unsaved_changes(). | 21:26.10 |
| | this means that if you try to open a broken file in android and you try to back out of the document you will be prompted to save the file "because it has changes". that's a bit unintuitive imho. | 21:26.59 |
| | had it been a form document then I wouldn't have protested, but setting the dirty flag just because we have been repairing doesn't seem so right, given the prevalence of broken documents...? | 21:27.51 |
| | paulgardiner: also it might be wise to update the titlebar (or something) in the filebrowser to show the (truncated?) path one is currently looking at. | 21:30.28 |
| | I'm unsure how other apps do it. | 21:31.10 |
| zygew | ask a question related mupdf.. | 22:00.09 |
| | i found the mupdf has rotate function by using a,s key.. | 22:00.31 |
| | do any other text viewr has similar function ? | 22:00.58 |
| | notepad | 22:01.02 |
| sebras | zygew: not that I have seen, no. | 22:08.06 |
| | zygew: they might have a function to rotate by 90 degrees perhaps, but not by 15 degrees like mupdf does. | 22:08.26 |
| | zygew: also note that this is only eneabled in debug builds, not release builds. | 22:08.57 |
| | tor8: Robin_Watts: a minor fix on sebras/master -- for commented out code, but still. | 23:28.23 |
| | moreover I merged openjpeg 1.5.1 over at git://git.ghostscript.com/user/sebras/openjpeg.git | 23:28.45 |
| | and updated the submodule sha1 in mupdf in HEAD over at sebras/master | 23:29.04 |
| | (ps. don't forget git submodule update --init) | 23:29.15 |
| | I saned it and that looked good. | 23:29.27 |
| | then I insaned it (using my own set of test-files) and found one regression. | 23:29.48 |
| | a complete jpx-image appears not to be rendered anymore. | 23:30.17 |
| | haven't figured out why yet. | 23:30.26 |
| | Forward 1 day (to 2012/12/20)>>> | |
IRC Logs