| | <<<Back 1 day (to 2013/06/02) | 2013/06/03 |
| Kausik | hi | 07:22.38 |
| | Hi | 07:23.48 |
| ghostbot | moin moin | 07:23.49 |
| sebras | ghostbot: hi | 08:21.01 |
| ghostbot | salut, sebras | 08:21.01 |
| sebras | tor8: morning. when you wake up have a look at sebras/master. | 08:21.31 |
| tor8 | sebras: pushed to tor/master, if you'll give them an okay there I'll push to master | 08:47.50 |
| sebras | tor8: looks good to me. | 09:00.47 |
| | tor8: one thing though.. why is the bidi-reordering done when freeing user? | 09:01.07 |
| tor8 | sebras: because that's when the device knows the page is complete | 09:01.44 |
| | I have considered adding begin-page and end-page calls to the device interface | 09:03.06 |
| sebras | tor8: so where is the reordered text transfered to the application? | 09:03.08 |
| tor8 | that would possibly help with robin's multipage devices | 09:03.18 |
| sebras | tor8: sounds like a good idea. I know you have mentioned this a long time ago. | 09:03.32 |
| Robin_Watts | tor8: begin_page/end_page sound sensible to me. | 11:09.35 |
| tor8 | Robin_Watts: do you want to, or should I? | 11:09.58 |
| | are you back home or still in the US? | 11:10.15 |
| Robin_Watts | Back home now. | 11:10.23 |
| tor8 | for four days before your next trip? ugh, that must give you awful jet lag... | 11:10.52 |
| Robin_Watts | tor8: it seemed like a good idea at the time :) | 11:11.10 |
| tor8 | I upgraded to Gtk+ 3 and everything is behaving differently... | 11:11.16 |
| | same function calls, completely different behaviour | 11:11.28 |
| | at least it doesn't seem to be automatically threading stuff in the background anymore :) | 11:11.47 |
| | I even got it to kernel panic my linux VM | 11:12.04 |
| | malloc on linux overcommitting memory and crashing the app when it finally runs out is one thing, but doing it by kernel panic seems a bit ... overkill | 11:13.06 |
| Robin_Watts | tor8: A few reviews on robin/master | 11:37.08 |
| | I'm gonna look at mvrhel's winrt stuff today too. | 11:37.19 |
| tor8 | Robin_Watts: okay. I looked briefly at it, but there was some multithreading/locking I felt you'd be better off checkig. | 11:37.55 |
| | (the winrt stuff, that is) | 11:38.06 |
| | Robin_Watts: zeniko has started using github, so you can add his repo there as a remote and pull his fixes in | 11:38.34 |
| | there's a handful up we should review | 11:38.40 |
| | git remote add zeniko git://github.com/zeniko/mupdf.git | 11:39.06 |
| | Robin_Watts: svg fix and negative xstep/ystep LGTM | 11:42.00 |
| | I don't understand the math in step<area | 11:42.14 |
| Robin_Watts | Suppose you have an area of 0,0 -> 100,100 | 11:43.19 |
| | and a step of 50,50 | 11:43.25 |
| | Each tile should overlap it's neighbour by 50% | 11:43.47 |
| | or (if you prefer) each pixel is drawn as part of 4 tiles) | 11:44.06 |
| | hence in our calculation of "what's the left most tile repeat we need to draw" we need to allow for the difference between the width of the area, and the xstep. | 11:44.47 |
| tor8 | Robin_Watts: I'm out of touch with this code | 11:44.57 |
| | what does the "area" represent? | 11:45.44 |
| | there are two rectangles coming in, area and view | 11:45.56 |
| | in pdf they should be the same rectangles, but in different coordinate spaces | 11:47.23 |
| | (and probably the same idea in xps) | 11:47.49 |
| Robin_Watts | tor8: For simplicity, let's imagine a 1:1 ctm. | 11:48.42 |
| | so, we draw the pattern into a tile of size 'area'. | 11:49.00 |
| malc | tor8: any clue what bidi_reordering doing in text device deallocation function? | 11:49.04 |
| tor8 | malc: it's there because it's the only place we can run code at "page end" time | 11:49.26 |
| Robin_Watts | then we repeatedly stamp that tile at repeats of xstep/ystep. | 11:49.28 |
| tor8 | malc: I'm adding begin/end-page device calls to make it a bit more logical | 11:49.37 |
| Robin_Watts | Normally, xstep/ystep >= the width/height of the area, right? | 11:49.49 |
| | if xstep=width then we get no gaps between repeats. | 11:50.02 |
| tor8 | area is derived from xstep/ystep...? | 11:50.11 |
| Robin_Watts | if xstep > width then we get gaps. | 11:50.14 |
| | no. | 11:50.16 |
| tor8 | at least that's what I vaguely remember | 11:50.17 |
| Robin_Watts | area is independent of xstep/ystep. | 11:50.25 |
| | Look at fts_15_1506.pdf | 11:50.30 |
| | In particular the 5,30 one. | 11:51.21 |
| | That's the same pattern as all the others. | 11:51.43 |
| tor8 | oh, right. so area is the area to be filled? | 11:51.46 |
| Robin_Watts | indeed. | 11:51.51 |
| | If you view that file in mupdf then you'll note the left hand and bottom edges look wrong. | 11:52.26 |
| tor8 | area=part of page to fill with tile | 11:53.26 |
| | view=size of one tile | 11:53.31 |
| | both in pattern space | 11:53.37 |
| Robin_Watts | sounds plausible. | 11:53.49 |
| tor8 | looking at the xps code that seems to be the case | 11:54.02 |
| Robin_Watts | I'd have to check the comments I added last time I looked at this :) | 11:54.12 |
| tor8 | so I don't understand what xstep/ystep have to do with area at all... | 11:55.05 |
| | if anything, they have to do with "view" | 11:55.14 |
| Robin_Watts | so maybe I should be using view... let me check. | 11:56.08 |
| tor8 | if the area is smaller that the step, we won't be calling begin/end_tile | 11:56.09 |
| | if the area is bigger than the step, we get the number of iterations to use in that x0/y0/x1/y1 calculation | 11:56.32 |
| | area is the scissor region, but in the pattern coordinate space | 11:56.50 |
| | (of course it may be bigger, if the display list is involved) | 11:57.12 |
| Robin_Watts | Right. area is the scissor region for a single tile, I believe. | 11:57.17 |
| tor8 | state[i].area = area passed into fz_begin_tile | 11:57.56 |
| | that area is the scissor region for the part of the page to be filled | 11:58.14 |
| | nothing to do with individual tiles | 11:58.20 |
| Robin_Watts | OK, so view on entry is the size of the individual tile. | 12:05.46 |
| | We map that through ctm to get the bbox. | 12:06.54 |
| | the bbox gets put into 'scissor'. | 12:07.00 |
| | So the old code used to calculate how many repeats of the tile were required by taking area and dividing it by xstep/ystep. | 12:07.31 |
| | and that's fine, except for when the tile self-overlaps. | 12:07.43 |
| | In that case, we need to include extra repeats of the tile to the left and below. | 12:08.05 |
| tor8 | self overlapping tiles are impossible in xps | 12:08.33 |
| Robin_Watts | hence we modify the calculation of the left/bottom repeat bounds (x0 and y0) | 12:08.38 |
| tor8 | and we can't possibly hope to get that right using the begin_tile/end_tile logic | 12:08.58 |
| Robin_Watts | by subtracting the difference between the width of the tile (scissor.x1-scissor.x0) and the xstep. | 12:09.16 |
| tor8 | what if the width/xstep is not evenly divisible | 12:09.24 |
| Robin_Watts | tor8: We aren't relying on it being evenly divisible. | 12:09.46 |
| tor8 | in xps the xstep/ystep and "view" box are one and the same (no overlaps or gaps) | 12:10.46 |
| | in pdf the xstep/ystep and "view" may be different | 12:10.54 |
| Robin_Watts | Right, so in xps, we'll get no change. | 12:11.01 |
| tor8 | where the view can be bigger than xstep | 12:11.04 |
| Robin_Watts | i.e the xstep - view.width = 0, hence the calculation doesn't change. | 12:11.23 |
| tor8 | so we ought to be taking into consideration how much bigger the view is than xstep | 12:11.28 |
| | so the scissor shouldn't be part of it, but the view should. | 12:12.00 |
| Robin_Watts | scissor = view. | 12:12.09 |
| | scissor = view.ctm, more correctly. | 12:12.26 |
| tor8 | Robin_Watts: only in rectilinear cases | 12:12.30 |
| | what if the pattern is rotated? | 12:12.46 |
| Robin_Watts | right, so in non-rectilinear cases, we may get more repeats than we need. | 12:12.56 |
| | but we already do. | 12:13.02 |
| | In rotated cases, we draw the pattern rotated onto a tile that is larger than it needs to be. | 12:13.46 |
| | i.e. we rotate the tile bounds, and take a bbox from that. | 12:13.59 |
| tor8 | right! | 12:14.24 |
| | could you add a comment to mention that state[0].scissor is derived from the "view" size of one tile | 12:15.44 |
| Robin_Watts | Sure. | 12:15.52 |
| tor8 | the patch makes sense now | 12:15.59 |
| Robin_Watts | SVG output of this file is screwed up though. The pattern is shifted slightly. | 12:16.28 |
| tor8 | I had to go chasing a lot of variables to confirm where scissor came from | 12:16.30 |
| Robin_Watts | tor8: yeah. me to on the plane yesterday :) | 12:16.44 |
| tor8 | Robin_Watts: the PCL patch, I'm not happy how all the pcl option structs are in fitz.h | 12:17.08 |
| Robin_Watts | tor8: Right. I figure that needs discussion. | 12:17.25 |
| tor8 | name/int pairs would work for all the pcl options, so we could make it an opaque struct and call fz_set_pcl_option(fz_pcl_options *opts, char *name, int value) | 12:19.20 |
| | fz_set_pcl_preset("ljet4") etc? | 12:19.47 |
| Robin_Watts | tor8: We could, yes. Wouldn't that go against the whole 'no bloat' thing? | 12:20.38 |
| tor8 | hm? what specifically do you mean would go against 'no bloat'? including pcl output at all? | 12:21.24 |
| | or 'too many functions'? | 12:21.37 |
| Robin_Watts | The code as written now has a few enums - if you don't use 'em they compile right out. If you do use them there is no overhead. | 12:22.05 |
| tor8 | the same would be true of string literals... | 12:22.45 |
| Robin_Watts | If we move to an 'fz_set_pcl_preset' thing, then everything we have now is still there, but we have an additional layer to do runtime translation from string to preset. | 12:23.01 |
| | and fz_set_pcl_option maps from string to enum. | 12:23.22 |
| tor8 | the "static const struct ...option..." I'm less confident that compilers would do the right thing | 12:23.24 |
| paulgardiner | I thought enums had no overhead independently of whether you use them. | 12:23.28 |
| tor8 | Robin_Watts: strings are more stable w.r.t. binary compatibility between library versions :) | 12:23.59 |
| | and setting up device options is hardly performance critical | 12:24.16 |
| | and easier to extend | 12:24.24 |
| Robin_Watts | tor8: Possibly we should have those as: const fz_pcl_options blah; in fitz.h | 12:24.50 |
| | and the actual definitions within the .c | 12:24.58 |
| tor8 | also, strings don't bloat the header with a thousand enums :) | 12:25.01 |
| Robin_Watts | that way the compiler would correctly elide them. | 12:25.06 |
| | but it's harder to extend them. | 12:25.19 |
| tor8 | Robin_Watts: yeah. if going with global structs, that's the way to do it. | 12:25.21 |
| Robin_Watts | using strings is *harder* to extend them. | 12:25.34 |
| tor8 | but I think having a more "dynamic" options interface is easier | 12:25.37 |
| | ...easier for users. | 12:25.53 |
| Robin_Watts | cos you have the enum internally anyway, plus you need code to map from string to enum. | 12:25.59 |
| | right. This is where multiple headers would be a win. | 12:26.09 |
| | #include "fitz/pcl_options.h" | 12:26.23 |
| tor8 | I have no problem with the pcl mode enums | 12:26.27 |
| | but enums for keys in the fz_meta interface, I'm not so fond of | 12:26.39 |
| | enums for values, yes. enums for keys, not so much. | 12:26.59 |
| Robin_Watts | tor8: Ah, enums for keys in fz_meta are crucial, IMHO. | 12:27.05 |
| | fz_meta is potentially a time critical interface, hence string comparisons would be bad. | 12:27.28 |
| tor8 | fz_meta is not performance critical. and the fz_meta interface is supposed to be extensible? | 12:27.31 |
| | oh. where is it time critical? | 12:27.42 |
| Robin_Watts | tor8: currently it's not, but it *could* be. | 12:27.53 |
| tor8 | I thought it was something you'd call at document loading time to get stuff like document titles and all the "dublin core" xml crap eventually | 12:28.12 |
| Robin_Watts | certainly in circumstances where I've used similar things before it ended up being time critical. | 12:28.14 |
| tor8 | I don't think it's something that would be called even at the page level granularity | 12:28.41 |
| | Robin_Watts IMO: #include "mupdf/pcl_options.h" and then we should move fitz.h into "mupdf/fitz.h" and all the other header files and split them by module rather than public/internal | 12:29.52 |
| paulgardiner | Is this if (!strcmp) else if (!strcmp) else if (!strcmp) vs switch ? | 12:31.02 |
| Robin_Watts | paulgardiner: That's the argument, yes. | 12:31.16 |
| tor8 | paulgardiner: yes. | 12:31.20 |
| Robin_Watts | I *loathe* if (!strcmp) ... | 12:31.25 |
| tor8 | that's only because C makes looking up strings painful | 12:31.39 |
| Robin_Watts | tor8: It's not C compilers, it's microprocessors :) | 12:32.04 |
| paulgardiner | I like the easy extensibility of strings, but I have to admit I've regretted using them in the past | 12:32.18 |
| tor8 | I think title = fz_meta(doc, "title") is better than title = fz_meta(doc, FZ_META_TITLE) | 12:32.36 |
| paulgardiner | On the other hand, that was looking up interfaces in a COM-like scenario, which is more likely to be time critical | 12:33.22 |
| tor8 | but that's "write language bindings" and a fondness for scripting languages speaking | 12:33.24 |
| | "atoms" as in XInternAtom solve both issues neatly | 12:33.50 |
| | strings, with performance | 12:33.57 |
| | in pcl options, the "features" is a list of capabilities. I think that sort of thing sits uncomfortably as a bitmask masquerading as enums. it's inextensible past the number of bits you happen to allocate in the interface. | 12:36.39 |
| | a public interface for that would be better served without exposing the internal nature of using bitmasks | 12:36.59 |
| | be it via strings or selector enums (rather than bitmasks) | 12:37.16 |
| Robin_Watts | tor8: OK. I can play with that. | 12:37.18 |
| tor8 | currently only 11 bits used, and PCL probably won't grow past that, but you can understand my hesitation for that sort of interface | 12:38.28 |
| Robin_Watts | I can. | 12:39.01 |
| tor8 | we still have the same sort of thing with the device hints though, so I'm as guilty as anyone :) | 12:39.11 |
| | keep the current struct and enums, but namespace them and move the presets into the C file (and looked up by string name) and I'll be happy | 12:40.14 |
| | and once that's done, can we think about viciousy hacking up our header files? | 12:41.06 |
| | I'm unhappier every day witth navigating the header files... | 12:41.49 |
| Robin_Watts | tor8: sure. | 12:46.32 |
| | tor8: That sounds like a job for a long haul flight to me. | 12:46.53 |
| | tor8: OK, rebased on robin master | 13:03.10 |
| | I'm gonna grab some lunch, then look at mvhrel's, then tweak the PCL stuff. | 13:04.05 |
| tor8 | Robin_Watts: typo/mistake in the xstep comment. you probably mean view when you say area. | 13:05.22 |
| | Robin_Watts: I've pushed the first two that are okay. | 13:06.11 |
| kens | Robin_Watts : : Stack Overflow question for you: | 13:15.59 |
| | http://stackoverflow.com/questions/16879011/last-line-of-text-cut-off-when-extracting-text-from-pdf-using-mupdf | 13:16.00 |
| | And for tor8, paulgardiner or Robin_Watts : | 13:16.32 |
| | http://stackoverflow.com/questions/16872731/how-to-search-phrase-on-pdf-files-and-highlight-the-phrase-in-android | 13:16.32 |
| | Bit that last one looks like a dumb question, not wnough information to answer it | 13:16.55 |
| tor8 | Robin_Watts: possible bug in fz_run_display_list (BEGIN_TILE uses node->rect without transforming by top_ctm) | 13:17.08 |
| kens | I notice that its been tagged with bot MuPDF an iText | 13:17.13 |
| tor8 | kens: have you seen sebras harvest of probably infringing free apps based on mupdf? 26 of 'em... | 13:18.18 |
| kens | tor8 I had no idea he'd found so many :-O | 13:18.35 |
| tor8 | maybe we should answer all stackoverflow questions about mupdf with a prompt "are you complying with the GPL?" | 13:18.46 |
| | about mupdf on android, more specifically | 13:18.57 |
| kens | That will keep Scott and Miles busy | 13:18.57 |
| | tor8 yes that last one crossed my 'who are you and what are you doing' trigger too | 13:19.19 |
| | I did reply to that one asking which library theywere actually using, since they tagged it with both MuPDF and iText | 13:19.46 |
| tor8 | kens: I answered the first question | 13:20.12 |
| kens | thanks tor | 13:20.19 |
| tor8 | especially when they say "urgent plz halp!" | 13:20.26 |
| sebras | tor8: :) | 13:20.44 |
| | I didn't mean to keep Scott and/or Miles occupied, but I was curious whether anyone was actualy using it and I wanted to let you guys know what I found. | 13:21.21 |
| kens | sebras we certainly appreciate you finding this all out | 13:21.37 |
| | I'm sure Scott and Miles will be happy to send people emails gently chiding them, too | 13:22.11 |
| sebras | tor8: were all of my findings correct? | 13:22.36 |
| | did you check them all? | 13:22.44 |
| tor8 | sebras: I have only checked the first couple you sent on saturnday morning, haven't been through the rest yet | 13:23.11 |
| sebras | oh and the 50000-free-ebooks-thing I suggest you install on a device where you don't care about your account, because it seemed to request a lot of strange permissions. | 13:23.39 |
| Robin_Watts | tor8: typo fixed, and pushed to robin/master | 13:41.17 |
| tor8 | Robin_Watts: fab. I've pushed to origin. | 13:43.01 |
| mvrhel_laptop | henys you there? | 13:57.35 |
| | henrys | 13:57.39 |
| henrys | yup | 13:57.48 |
| mvrhel_laptop | I am going to out this morning. my coauther is in town for the day so I was going to go meet with him | 13:58.23 |
| henrys | sure no problem | 13:58.43 |
| mvrhel_laptop | ok. Robin_Watts if you see any issues in the winRT stuff you can email me please . I will work on what you find tonight | 13:59.15 |
| Robin_Watts | mvrhel_laptop: will do. | 13:59.25 |
| mvrhel_laptop | thanks | 14:00.10 |
| | tor8: do open xps files work with mupdf? | 14:00.19 |
| tor8 | mvrhel_laptop: they should, but it's largely untested. if you have any files that don't work please pass them this way and I'll look. | 14:00.54 |
| mvrhel_laptop | ok. I will send one. it was a print out with the oxps windows 8 driver of the xps spec | 14:01.26 |
| malc | sebras: your (/F) patch doesn't seem to work | 14:01.53 |
| mvrhel_laptop | tor8: but I will verify that I had not screwed up something before bothering you with it | 14:02.49 |
| henrys | alexcher_: see shelly's message to Robin_Watts and make sure he has jbig2/jpeg2 problems to work on. | 14:05.25 |
| Robin_Watts | henrys: zeniko has some patches that need reviewing too. | 14:09.06 |
| henrys | Robin_Watts: forward or assign to alexcher_, I'll also send him email to read the logs. | 14:10.34 |
| | Robin_Watts: don't unpack ;-) | 14:10.43 |
| Robin_Watts | henrys: I didn't get the Paul Revere gag the other day until I was reading the history as we walked the Freedom Trail. | 14:11.39 |
| henrys | Robin_Watts: Every american school kid learns that ⦠I doubt it is well known elsewhere. | 14:14.09 |
| Robin_Watts | mvrhel_laptop: Is ZoomToFactor a standard method ? | 14:19.46 |
| | mvrhel_laptop: As a general rule in mupdf, you can 'free' NULL things. | 14:21.05 |
| | So you don't need to do: if (x) fz_free_xxx(ctx, x); | 14:21.23 |
| | i.e. the if is not required. | 14:21.32 |
| | mvrhel_laptop: All seems fine to me. | 14:22.57 |
| mvrhel_laptop | Robin_Watts: ok. I will remove the check | 14:29.16 |
| | thanks | 14:29.18 |
| Robin_Watts | mvrhel_laptop: checks don't hurt - we sometimes check elsewhere in the code. For performance critical stuff, checking can save an unnecessary function call, but... | 14:30.48 |
| | tor8: If we're going to reorganise header files, I wonder if we should have a directory restructuring too. | 14:36.28 |
| | We did a big reorganisation at Picsel when we took our (already modular) code and shuffled it about. | 14:37.10 |
| | Initially we built all our code as .o's and linked a whole batch of .o's into the final exe. | 14:37.29 |
| | but (for various reasons) we wanted to modularise it into libs that would be linked together. | 14:37.53 |
| | There were some things we wanted to achieve as part of the reorganisation: | 14:38.17 |
| | 1) We wanted the API to be distinct from the implementation (even when implementations were shared across multiple .c files) | 14:38.40 |
| | So for each module we had an 'api' directory that contained a directory with the name of the module, then the api header files in that. | 14:39.44 |
| | And we'd have -Iapi | 14:40.00 |
| tor8 | Robin_Watts: we could probably improve that too. I'm a bit concerned about having too many -I directives on one command line though. unless of course we're strict about only having the -I that we need for each module | 14:40.37 |
| Robin_Watts | so you'd do: #include "fitz/pixmap.h" or something. | 14:40.46 |
| | We might only need a single 'api' directory. | 14:41.12 |
| tor8 | right. that was what I was thinking. have one "mupdf" directory which has one header per module | 14:41.31 |
| | and a convenience "fitz.h" for clients to use, but which we'd phase out internally | 14:41.53 |
| Robin_Watts | tor8: but that's distinct from the source dirs, right ? | 14:41.57 |
| tor8 | distinct from source dir | 14:42.03 |
| Robin_Watts | OK. So APIs are always included with the full name: "mupdf/pixmap.h" | 14:42.19 |
| tor8 | I was thinking "mupdf/pixmap.h" and "pixmap/pixmap-stuff.c" | 14:42.25 |
| | mupdf/draw.h and draw/draw_*.c | 14:42.41 |
| Robin_Watts | For the pixmap example... | 14:42.53 |
| | the api's would be in mupdf/pixmap.h" | 14:43.04 |
| | Personally, I'd then have a "pixmap-impl.h" in the source, so that the pixmap .c files can #include "pixmap-impl.h" to get the implementation details. | 14:43.44 |
| tor8 | and pixmap-imp.h would live with the sources? | 14:43.58 |
| Robin_Watts | yes. | 14:44.06 |
| tor8 | I like that. | 14:44.09 |
| | it keeps module-internals shared between per module files but out of the public APIs | 14:44.23 |
| Robin_Watts | It separates ".h files that define the API" from ".h files that are private to the source" | 14:44.38 |
| | yeah. | 14:44.40 |
| | and it greatly improves the ability of the linker to elide functions that aren't used (as those functions can be split into separate .c's) | 14:45.18 |
| tor8 | how do you feel about adding a "source" directory to keep the module directories | 14:45.28 |
| | I'm conflicted, convenience wants me to have the module directories at the top level, but it's confusing to have too many directories and files at the top level | 14:45.58 |
| Robin_Watts | tor8: I would not be offended by that, but I think that we could avoid it if we wanted to. | 14:46.03 |
| | We ought to have either an 'api' or an 'include' dir, but the sources could go into 'source' or not, as we feel like. | 14:46.26 |
| tor8 | or just move the android, ios, winrt, etc directories into apps/ | 14:46.28 |
| | so it'd be ~/src/mupdf-work-directory/include/mupdf/fitz.h ? | 14:46.57 |
| Robin_Watts | If we really want to go OCD on it, we should have a platform directory within which things life. | 14:47.06 |
| | yes. | 14:47.08 |
| tor8 | or just ~/src/mupdf-work-directory/mupdf/fitz.h ? | 14:47.16 |
| Robin_Watts | the former. | 14:47.24 |
| | so we do -Iinclude | 14:47.31 |
| tor8 | okay. | 14:47.35 |
| | I can live with that | 14:47.42 |
| | clearer but less convenient :) | 14:47.51 |
| Robin_Watts | That way, people *can't* accidently include private stuff. | 14:48.25 |
| | (they have to deliberately go adding new include paths to mess where they shouldn't be) | 14:48.46 |
| tor8 | with the latter we'd do -I. (at the top level) so you'd have to write #include "mupdf/fitz.h" | 14:49.05 |
| | not -Imupdf, if that's what you thought I meant | 14:49.17 |
| Robin_Watts | tor8: we can either have the api dirs at the top level, or the source dirs, but not both, IMHO. | 14:49.56 |
| tor8 | still, I think I would be okay with separate "include", "source", "generated" and "data" directories at the top level | 14:49.58 |
| | basically deepening source and data files by one level | 14:50.11 |
| Robin_Watts | yeah. | 14:50.23 |
| tor8 | prefer the source dirs at the top level in that case | 14:50.24 |
| Robin_Watts | me too. | 14:50.30 |
| | tor8: Just looking at zenikos patches. | 14:52.56 |
| tor8 | malc: sebras says he'll look at that in an hour or two | 15:06.30 |
| tkamppeter | henrys, Robin_Watts, about bug 694279, the duplex problem of the PCL 5(e) drivers, the user succeeds to print correctly (one-sided, duplex long/short edge, correct margins) on his Brother printer when he uses the HPIJS driver of HPLIP, so you should perhaps compare Ghostscript's ljet4/ljet4d output with HPIJS' output. | 15:08.40 |
| henrys | tkamppeter: I'll get to it but I'm working on other stuff now .. if you want to do it have at it! | 15:10.05 |
| tkamppeter | henrys, OK, I have also CCed Hin-Tak, as he often did fixes on PCL drivers, but he did not comment on this yet. | 15:15.52 |
| malc | tor8: thanks | 15:22.37 |
| Robin_Watts | tor8: pushing zenikos patches (very slightly tweaked) | 15:22.59 |
| kens | Robin_Watts : how bad was the immigration queue at Boston ? | 15:26.43 |
| Robin_Watts | kens: 1 hour. | 15:26.50 |
| kens | Well, that's not too bad :-( | 15:27.00 |
| Robin_Watts | yeah. | 15:27.13 |
| kens | THe newspaper was predicting 3.5 at Miami | 15:27.17 |
| Robin_Watts | http://www.airlinequality.com/Airports/Airport_forum/mia.htm | 15:29.52 |
| | Reports vary there from 4 hours to 35 mins. | 15:30.02 |
| tor8 | eep! | 15:38.38 |
| | Robin_Watts: paulgardiner: hmm. when adding fz_begin/end_page calls to pdf I ran into a small problem | 15:49.34 |
| | the split of run_page_contents and run_annot... | 15:49.51 |
| | I could put the calls to begin/end page into fz_run_page, but then anyone using annots explicitly will miss those calls | 15:50.47 |
| Robin_Watts | tor8: Ah. | 15:58.42 |
| paulgardiner | Oh nasty | 15:59.23 |
| Robin_Watts | Refresh my memory as to how this works. | 15:59.23 |
| | Does fz_run_page do: fz_run_page_contents then fz_run_annot ? | 15:59.47 |
| | If so, can we have fz_run_page do: fz_begin_page, fz_run_page_contents, fz_run_annots, fz_end_page ? | 16:00.21 |
| tor8 | you mean leave the responsibility to call fz_begin_page to the user if using explicit run_page_contents / annots? | 16:01.08 |
| Robin_Watts | So, people that call fz_run_page_contents or fz_end_page should call fz_begin/end_page themselves ? | 16:01.09 |
| tor8 | that would work I think | 16:01.15 |
| Robin_Watts | I understand the need for fz_end_page. | 16:01.30 |
| | Why do we need fz_begin_page ? | 16:01.37 |
| | (can we have the fz_null layer call fz_begin_page on the first call of any function on a device? and call fz_end_page automatically on the device free?) | 16:02.32 |
| tor8 | Robin_Watts: I was thinking it'd be handy for your multi-page devices | 16:04.27 |
| | create one multi-page device and run many pages | 16:04.35 |
| Robin_Watts | tor8: right. | 16:04.36 |
| | and I absolutely agree that that's useful. | 16:04.47 |
| | but we could make the dev_null layer call it if required so existing single page use doesn't need changes. | 16:05.07 |
| | we have a 'has_begun_page' flag. | 16:05.27 |
| tor8 | several people have run into the gotcha of the text device not having the final line because they haven't freed the text device in time | 16:05.37 |
| | the begin page call would handily have the page mediabox in it too | 16:05.56 |
| | which would communicate that info to multi-page devices as well | 16:06.15 |
| Robin_Watts | page media box and maybe page title or page number? | 16:06.25 |
| tor8 | Robin_Watts: existing single page use shouldn't be affected, nor simple users of fz_run_page | 16:06.41 |
| | we could add page numbers, but that's going to require some additions to the pdf_page struct to save the number :) | 16:07.28 |
| Robin_Watts | tor8: possibly fz_begin_page should take a pointer to a struct with information in, such as the mediabox. | 16:08.21 |
| | That way we can extend the struct without breaking the interface in future. | 16:08.34 |
| tor8 | we could pass in the fz_page struct maybe | 16:09.19 |
| | I'll leave it as the dead simple just-a-mediabox for now | 16:09.29 |
| | that doesn't need any tweaking of the display list | 16:09.45 |
| Robin_Watts | tor8: So, suppose I write a new device that relies on fz_begin_page being called. | 16:10.10 |
| | old code won't call it, right? | 16:10.20 |
| tor8 | Robin_Watts: old code will call fz_run_page, which will call it | 16:10.30 |
| Robin_Watts | fair enough. | 16:10.46 |
| tor8 | it's just those who use separate calls for fz_run_page_contents, fz_run_annot that need to change | 16:11.00 |
| | Robin_Watts: patches up on tor/master | 16:18.09 |
| | Robin_Watts: the null layer could/should probably have a device hint for whether a given device is multi-page or single-page and throw errors if beginpage is called more than once on single page devices | 16:20.09 |
| Robin_Watts | tor8: nice. | 16:20.36 |
| kens | Goodnight everyone | 16:22.12 |
| tor8 | Robin_Watts: and fix to text device to move span soup straining and bidi reordering | 16:23.50 |
| Robin_Watts | tor8: Fab. Just doing some email, will look asap. | 16:24.24 |
| tor8 | Robin_Watts: return value of dev->begin_tile and id argument? I'm writing a fz_tee_device for running multiple devices at once | 16:52.01 |
| Robin_Watts | If begin_tile returns 1, then that tile is cached, IIRC. | 16:52.37 |
| | hence we don't bother sending the tile contents. | 16:52.51 |
| | so you'd need to remember which of your devices said 1 and which said 0. | 16:53.23 |
| tor8 | so in a tee device, that'd be return ret_a && ret_b | 16:53.30 |
| Robin_Watts | and you'd return the AND of them. | 16:53.35 |
| | but if any of them said no, you'd need to only forward the contents to that one. | 16:53.49 |
| | sounds hellish. | 16:53.54 |
| tor8 | yeah. question is: does it hurt to forward to both anyway? | 16:54.24 |
| Robin_Watts | the question should be "*should* it hurt to forward to both anyway" :) | 16:54.44 |
| | I fear in the cached case, you'll redraw onto the existing tile. | 16:55.11 |
| | currently at least. | 16:55.19 |
| | tor8: I was imagining that is_multi_page would be a device hint. | 16:56.31 |
| tor8 | send id -1 then? | 16:56.34 |
| | Robin_Watts: I thought that too at first, but since users can override hints it'd be a bit dangerous | 16:56.59 |
| Robin_Watts | tor8: ew. You'd be disabling all caching. | 16:57.03 |
| tor8 | and we need to keep track of page count anyway | 16:57.06 |
| Robin_Watts | tor8: right, I was thinking we'd specifically want to allow users to disable the error; imagine if I want to composite 2 pages together with different CTMs. | 16:57.38 |
| tor8 | Robin_Watts: yeah. not good. so I'd need a tile-cache-nesting-stack for inhibiting device calls to one. or just silently drop on the non-cached device. | 16:57.41 |
| | Robin_Watts: oh, right! | 16:57.58 |
| | well, we could just ignore that commit and be happy :) | 16:58.11 |
| | but the text device isn't safe for that | 16:58.25 |
| Robin_Watts | a hint seems the right solution to me. | 16:58.38 |
| tor8 | you may well be right. let's sleep on it. I need to get some dinner now. | 16:58.58 |
| Robin_Watts | tor8: yeah, I think the tee device would need some sort of state :( | 16:59.11 |
| | unless we specify that ALL devices MUST cope with being sent the contents, even though they may be cached. | 16:59.38 |
| tor8 | a first stab at a tee device (without users) on tor/master | 16:59.40 |
| Robin_Watts | so the draw device would know to skip for itself. | 16:59.57 |
| tor8 | or put that logic into the dev_null layer | 17:00.09 |
| Robin_Watts | so every device would get called if anyone needed it. | 17:00.16 |
| | tor8: that would require nasty nesting of information in dev_null, right? | 17:00.39 |
| ray_laptop | I finallly decided to look at bug 693509 (since the meeting is coming up soon :-) ) -- really strange. The clip rectangle is 0 width in page mode, but is 1 pixel wide in clist mode. | 17:01.06 |
| tor8 | we'd need to test the return value of fz_begin_tile_id and keep a stack of is-cached-tile | 17:01.22 |
| | probably very hairy | 17:01.31 |
| Robin_Watts | yeah, I dislike keeping a stack in dev_null. | 17:01.38 |
| | On the other hand, the draw device already has to keep a stack. | 17:01.51 |
| tor8 | but I think it'd be nice for the common use case for "draw the page bitmap and get the text out at the same time" | 17:01.57 |
| Robin_Watts | making it responsible for remembering for itself is probably less work. | 17:02.16 |
| tor8 | question is the possibly different ctms there | 17:02.22 |
| ray_laptop | 1 pixel wide matches Adobe's output. | 17:02.41 |
| Robin_Watts | tor8: The cache record for the tile includes the ctm. | 17:02.53 |
| tor8 | might not be worth bothering with, if you're willing to use the display list though | 17:02.53 |
| Robin_Watts | different ctm means uncached. | 17:03.03 |
| tor8 | Robin_Watts: I meant wanting different ctm on the A and B devices of the tee | 17:03.15 |
| Robin_Watts | tor8: why is that a problem? | 17:03.25 |
| tor8 | say I want identity for the text, and current zoom level for bitmap | 17:03.41 |
| Robin_Watts | oh, in terms of using the device, right. | 17:03.53 |
| | That's very true. | 17:03.57 |
| tor8 | but that's even hairier to fix | 17:04.03 |
| Robin_Watts | How common is the tee thing? | 17:04.08 |
| | I can't think of an application in our code that would actually use it. | 17:04.26 |
| tor8 | I was thinking it might help the viewers that want to use less memory and not haul around the display list | 17:04.37 |
| | and still be able to get the text out at the same time as drawing a bitmap | 17:05.00 |
| | but it may not be worth bothering with. just wanted to see if it was easy enough to do. | 17:05.15 |
| Robin_Watts | We never want the text at the same time as drawing the bitmap. | 17:05.21 |
| tor8 | turns out, tile caching throws a spanner into the works :( | 17:05.26 |
| Robin_Watts | We might want to show the bitmap, THEN do text->speech, but that's a second pass. | 17:05.39 |
| tor8 | Robin_Watts: that second pass will need re-parsing in the non-display-list case | 17:05.57 |
| Robin_Watts | tor8: right. | 17:06.03 |
| tor8 | which is what I was hoping to avoid | 17:06.03 |
| | in the presence of memory gobbling display lists, not a problem | 17:06.19 |
| ray_laptop | tor8: and Robin_Watts: I don't see in the PDF spec if it defines what a clipping path of a zero width path is supposed to do. Do either of you know what it's supposed to be (and where it's defined) ? | 17:20.54 |
| Robin_Watts | It's undefined in the spec, I believe. | 17:21.10 |
| ray_laptop | great :-( What does mupdf do ? | 17:21.27 |
| Robin_Watts | but acrobat sometimes treats it as "covering any parrt of a pixel". | 17:21.30 |
| | There is a gs bug open about it. let me find it. | 17:21.47 |
| ray_laptop | it's the one I mentioned above | 17:21.59 |
| | or at least that one has it in there. | 17:22.11 |
| Robin_Watts | http://bugs.ghostscript.com/show_bug.cgi?id=690036 | 17:22.23 |
| ray_laptop | bug 693509 | 17:22.24 |
| Robin_Watts | I have to run, sorry. | 17:22.37 |
| ray_laptop | Robin_Watts: OK. Thanks. Two bugs then | 17:22.52 |
| | So I just have to find out why the clist mode works and fix the page mode clipping to match it | 17:25.04 |
| | At least Igor identified where it was in the spec. | 17:25.35 |
| | I found the reason that the clist mode uses the "correct" boundaries. It uses the clip accumulator device and then fills the path, so the fill_adjust is applied. | 19:33.26 |
| | the clip_fill_rectangle of the 'clipper' device doesn't use the fill_adjust | 19:37.57 |
| | I'm testing a change to use the fill_adjust (it did in some cases and not in others). Lots of differences are expected, but not in the clist case. | 20:13.29 |
| | bbiaw | 20:14.33 |
| shelly | Robin_Watts: ping | 21:45.41 |
| | Forward 1 day (to 2013/06/04)>>> | |
IRC Logs