| | <<<Back 1 day (to 2016/08/10) | 20160811 |
| sebras | Robin_Watts: FYI: still working on the unified fz_archive. | 16:44.39 |
| | fredross-perry: I read you got reflow working..? | 16:45.00 |
| Robin_Watts | sebras: OK. There is 1 commit on robin/master if you wouldn't mind. | 16:45.00 |
| | (type3 bbox one) | 16:45.11 |
| fredross-perry | sebras - no, I just confirmed with Robin that for the short-term it's OK to do what we've already done on the old view, that is, to use HTML and one page at a time. | 16:45.52 |
| | Unless you have a different idea. | 16:45.58 |
| sebras | fredross-perry: seems reasonable to me. | 16:47.32 |
| fredross-perry | k | 16:47.43 |
| sebras | fredross-perry: I think tor8 may have ideas on how to improve reflow by converting pdf to html, but that code has not yet materialized AIUI | 16:48.06 |
| | Robin_Watts: will take a look. | 16:48.18 |
| | Robin_Watts: are bug report PDFs usually added to the cluster by default? | 16:49.52 |
| Robin_Watts | sebras: Not "by default". | 17:06.10 |
| | "by a process of much swearing" | 17:06.27 |
| | I will add them. | 17:06.52 |
| sebras | Robin_Watts: oh, _that_ process. I employ that process far too often for my own good. :) | 17:09.31 |
| chrisl | SOP I'd have thought...... | 17:11.36 |
| sebras | acquires new item "SOP". | 17:12.41 |
| chrisl | "Standard Operating Procedure" | 17:13.24 |
| sebras | mm I already found it online. :) | 17:14.01 |
| | Robin_Watts: I'm trying to understand the commit. | 17:14.06 |
| | Robin_Watts: did we respect FontBBox before? | 17:14.18 |
| Robin_Watts | We did. | 17:14.29 |
| | Eons ago, we didn't. We just bounded each glyph and used that. | 17:14.50 |
| | But that produced problems where glyphs were stupidly huge. | 17:15.03 |
| | so tor changed it to clip to the font bbox. | 17:15.13 |
| | but then we had files with a zero bbox. | 17:15.28 |
| sebras | Robin_Watts: which caused the invalid flag. | 17:15.40 |
| Robin_Watts | so I made the code spot that it was a zero bbox, and not clip in those cases. | 17:15.41 |
| | indeed. | 17:15.46 |
| | BUT then we have a file which has a crap (non-zero) bbox. | 17:16.02 |
| | So we have the new code. | 17:16.07 |
| sebras | Robin_Watts: and acrobat/whatever renders these fine? | 17:16.28 |
| Robin_Watts | sebras: Yes. | 17:16.34 |
| sebras | Robin_Watts: so if the t3 content stream has d1 then we try to observe that if that is not in conflict with the FontBBox., | 17:18.19 |
| Robin_Watts | yes. | 17:18.37 |
| sebras | Robin_Watts: and if it is in conflict we retain all strokes/whatever. | 17:18.46 |
| Robin_Watts | exactly. | 17:19.02 |
| sebras | and this differs from the case where the t3 content stream has no d1 in what way..? | 17:19.30 |
| | Robin_Watts: seems to me that we do no clipping either case..? | 17:19.52 |
| chrisl | It must have a d0 *or* a d1 | 17:20.10 |
| | d1 gives the (alleged) glyph bounding box, d0 just with width | 17:20.45 |
| Robin_Watts | d0 just *advance* width. | 17:20.57 |
| chrisl | d0 just the width | 17:20.58 |
| | Yes | 17:21.19 |
| sebras | but mupdf ignores that width I think. | 17:21.38 |
| | at least pdf_run_d0() doesn't appear to pick it up. | 17:21.55 |
| chrisl | It'll come from the Widths array, rather than the glyph | 17:22.04 |
| sebras | ok so d0 is totally redundant. | 17:22.35 |
| Robin_Watts | sebras: the values after d0 and d1 are redundnt, yes. | 17:22.49 |
| | the existence of the d0 in the stream has meaning. | 17:23.04 |
| sebras | Robin_Watts: for the color flag..? | 17:23.29 |
| Robin_Watts | yes. | 17:23.36 |
| sebras | I meant that d0 is also redundant wrt to Widths. | 17:23.46 |
| | Robin_Watts: so the real change in your commit is to remove the end of fz_bound_t3_glyph() and say that in this case we don't clip at all..? | 17:25.51 |
| Robin_Watts | Wee *never* clip to the FontBBox any more. | 17:26.28 |
| sebras | Robin_Watts: no, I get that. I'm just trying to figure out exactly when we did so in the old code. | 17:26.53 |
| Robin_Watts | We always clipped whenever it wasn't invalid. | 17:27.15 |
| sebras | and that was whenever !invalid_bbox regardless of if d1 is present or not.\ | 17:27.24 |
| | Robin_Watts: what producer was used to create the faulty pdf? is it a common one? | 17:28.01 |
| Robin_Watts | I dunno, offhand. | 17:28.37 |
| chrisl | Looks like one of them at least was from a Metacode to PDF converter..... from a company that I have encountered before | 17:31.06 |
| | Ironically, one of the slides on their homepage says "Are You Challenged by Poor Quality PDF Files?" | 17:32.30 |
| sebras | chrisl: :) | 17:32.39 |
| chrisl | Unfortunately, way too many people think that if Acrobat displays it how they expect, the file must be correct | 17:35.41 |
| sebras | Robin_Watts: it is 2am and i'm not smart enough right not to visualise font->bbox vs d1_rect and thinking about degenerate cases like empty bboxes. | 17:40.12 |
| | Robin_Watts: I'm thinking that we could use fz_intersect_rect() and then check if it is fz_empty_rect and if so do fz_bound_t3_glyph(). | 17:41.14 |
| | Robin_Watts: the comparisons you have added might do the same thing, but I'm not 100% we cover all cases. :) | 17:41.37 |
| | Robin_Watts: that is a detail though and apart from that it LGTM. | 17:41.51 |
| Robin_Watts | sebras: No, I don't want to check for a non empty intersection. | 17:42.04 |
| sebras | s/right not/right now/ | 17:42.07 |
| Robin_Watts | The d1 rect should be strictly included in the font bbox, other wise one of them is wrong. | 17:42.43 |
| sebras | Robin_Watts: doesn't that mean that they must intersect? | 17:43.09 |
| Robin_Watts | sebras: I require d1_rect = intersect(d1_rect, fontbbox) | 17:43.41 |
| | not intersect(d1_rect, fontbbox) != empty | 17:43.54 |
| sebras | Robin_Watts: oh, so basically fz_contains_rect()? | 17:44.25 |
| Robin_Watts | sebras: Yes. | 17:44.33 |
| | I should probably have called that. | 17:44.41 |
| | If I make that fix, are you happy? | 17:44.52 |
| sebras | Robin_Watts: would it make sense to add it? | 17:44.59 |
| | Robin_Watts: equally happy as I am now! :) | 17:45.22 |
| Robin_Watts | sebras: It wouldn't hurt, and it would be clearer, possibly. | 17:45.32 |
| sebras | Robin_Watts: yes. | 17:45.38 |
| Robin_Watts | Will fix, thanks. | 17:45.46 |
| sebras | Robin_Watts: and if there is a bug in the comparisons (there probably isn't but I'm to sleepy to see that right now). | 17:46.12 |
| | then we can fix fz_contains_rect() | 17:46.19 |
| Robin_Watts | right. | 17:46.24 |
| sebras | Robin_Watts: maybe we also use similar constructs elsewhere and then we can now have everything in one place. | 17:48.09 |
| | Robin_Watts: sorry to be a PITA, but at least I take reviewing seriously. :) | 17:49.13 |
| Robin_Watts | sebras: No, it's all good. This is the point of reviewing. | 17:49.58 |
| | We change from having code that's "good enough" or "well, I understood it when I wrote it, I think" to code that at least 2 people understand (or think they do, or are unoffended by at least) | 17:51.04 |
| sebras | Robin_Watts: yes, I'm a little bummed out that FontBBox cannot be used at all but it seems like it would be hard to detect arbitrary combinations of numbers and determine whether they should be considered invalid. | 17:51.16 |
| Robin_Watts | I'm picky with other peoples code, so it's only fair that people are picky with mine. | 17:51.16 |
| | FontBBox is used to validate the given d1_rect. | 17:51.36 |
| sebras | Robin_Watts: yes, but not for clipping. | 17:51.44 |
| | Robin_Watts: and it seems that was one of it's intended uses. | 17:51.55 |
| Robin_Watts | sebras: Well, we clip to d1_rect. | 17:52.02 |
| sebras | Robin_Watts: indeed. | 17:52.09 |
| Robin_Watts | and d1_rect should be inside font bbox. | 17:52.14 |
| sebras | Robin_Watts: and d1 shoudl be there. | 17:52.19 |
| Robin_Watts | so clipping to fontbbox won't gain us anything :) | 17:52.25 |
| sebras | Robin_Watts: unless the t3 glyph is missing d1 | 17:52.40 |
| | Robin_Watts: in which case we do no clipping at all, but then again those glyphs _should_ have a d1 | 17:52.56 |
| | Robin_Watts: AIUI | 17:53.04 |
| | Robin_Watts: would it make sense to add a fz_warn() if we see that case? | 17:53.41 |
| | Robin_Watts: just so it can be noticed and that file analyzed? | 17:53.55 |
| Robin_Watts | If the file doesn't have a d0 or a d1, we already warn. | 17:54.27 |
| sebras | Robin_Watts: at this point the prosecution rests, literally. | 17:57.33 |
| Robin_Watts | sebras: Thanks. Night! | 17:57.44 |
| Michael__ | help | 21:33.30 |
| Guest74053 | need some help | 21:34.03 |
| | I'm trying to get a quote for mupdf library please reach me at saimaram7@gmail.com | 21:35.40 |
| | thank you. | 21:35.43 |
| Michael__ | Hello | 23:18.50 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 23:18.50 |
| Guest10797 | I'm using mupdf for rendering pdf's and we have big clients all across the world like FAZ from Belgium etc. Lately I'm having memory issues when displaying pdf in landsacpe | 23:20.14 |
| | I'm currently dispalying two pages in landscape | 23:20.27 |
| | when I load large pdfs its running out of memory very luicky. please help me with this | 23:21.18 |
| | can contact me any time at saimaram7@gmai.com | 23:22.06 |
| HenryStiles | Guest10797: what is your application? | 23:40.39 |
| | Forward 1 day (to 2016/08/12)>>> | |
IRC Logs