| | <<<Back 1 day (to 2012/06/11) | 2012/06/12 |
| kens | tor8 ping | 08:15.49 |
| tor8 | hi kens | 08:17.27 |
| kens | tor8 been looking at XPS again | 08:17.39 |
| | specifically the office2007_eurotest file | 08:18.05 |
| | The reaosn page 1 is bitmapped is because it 'sort of' contains transparency | 08:18.20 |
| | I get a deivce push and pop at the start and end of the page | 08:18.33 |
| | But no other transparency operations | 08:18.43 |
| | Does that make sense ot you ? | 08:18.51 |
| | I seem to recall that we can't tell if an XPS docuemtn contains transparent operations | 08:19.06 |
| tor8 | our transparency tests aren't 100% accurate | 08:19.10 |
| kens | Ah... | 08:19.16 |
| | So perhaps it doesn't really contain any. OK that's not a problem | 08:19.31 |
| | I'm certainly not going to worry about it for XPS. | 08:19.46 |
| tor8 | let me look at this file. | 08:20.12 |
| kens | So on to the fonts on page 2 (again) | 08:20.15 |
| tor8 | kens: there' a path with alpha=0 in there | 08:21.56 |
| kens | Hmm, is that 100% opaque or 100% transparent ? | 08:22.16 |
| tor8 | 100% transparent | 08:22.21 |
| kens | So it has no actual effect then I guess | 08:22.30 |
| tor8 | which we optimize out when drawing, but not when testing for transparency | 08:22.55 |
| kens | Agh, that explains it hen. | 08:23.04 |
| | Not a problem, just explains why the page is bitmapped when going to PostScript | 08:23.18 |
| tor8 | revamping the transparency testing is on my todo list for another bug | 08:23.23 |
| kens | (but not when going to PDF) | 08:23.23 |
| | tor8 its not important at all | 08:23.33 |
| | From my point of view | 08:23.42 |
| tor8 | xps_brush_has_transparency is a two line patch to check for the fully transparent case :) | 08:24.30 |
| | but now we know why at least | 08:24.41 |
| kens | Yep, that's all I really wanted today | 08:24.52 |
| | I'll go back to scratching my head over the fonts again | 08:25.03 |
| tor8 | this is the characters in ps2write coming out all the same problem? | 08:25.35 |
| kens | Yes, thats the problem | 08:25.43 |
| tor8 | right. good luck :) | 08:25.52 |
| kens | Its trying to emit the font as a CIDFont, which won't work at all well with ps2write | 08:25.58 |
| | The font data it emits is partially garbage | 08:26.13 |
| tor8 | my guess would be that xps fonts are missing some vital callback or other behaviour | 08:26.17 |
| kens | tor8 I'm inclined to agree, but I'll poke it some more | 08:26.34 |
| | I may come back to you at some point | 08:26.41 |
| tor8 | it might be easier to just replace those with the freetype thing we keep talking about on the meetings :) | 08:26.54 |
| kens | chrisl is working on it, he tells me he's making progress | 08:27.18 |
| chrisl | I doubt that will help, though, | 08:27.30 |
| kens | with PCL, but XPS should be easier | 08:27.31 |
| | I'm inclined to agree chrisl | 08:27.40 |
| | I think the problem must be ps2write, because the pdfwrite output is OK | 08:27.52 |
| tor8 | kens: you could try the mooscript branch with ps2write, that has another bare bones font implementation that probably all turns into type 3 bitmap fonts | 08:28.30 |
| norbertj | tor8 good morning | 08:28.48 |
| chrisl | As I will be poking around that area (hopefully) later this week, I'll take note if I find anything suspicious...... | 08:28.49 |
| kens | Not too worry tor8 I'll start by following the text code. | 08:28.58 |
| tor8 | hi norbertj | 08:29.01 |
| norbertj | did you also have a look at 693042? I know it's assigned to mvhrel, but perhaps you have any idea what causes the extreem slowness | 08:29.48 |
| | the job as is consists only of 1 page, but it rips very slow (> 8-10 minutes (9.04) and even slower in 9.05. | 08:30.28 |
| | Perhaps some optimizations in the transparancy handling is needed (I was triggered by the conversation above;) | 08:31.00 |
| tor8 | norbertj: I have a suspicion, but I haven't studied it in detail. marcos bisected it down to a change mvrhel did. | 08:31.37 |
| | we used to ignore transparency for tiling patterns | 08:31.56 |
| | adding transparency handling in tiling patterns could very well be causing slowdowns | 08:32.23 |
| | there's a bug in the detection code for when transparency is needed in patterns (it doesn't catch all the cases it needs to), so fixing that will probably make it even slower :) | 08:32.58 |
| norbertj | tor8: that is for the slowdown. I know that there is a trade-off between quality-and-performance. But overall I wonder if the there could not also something be done on the overall bad rip-time for this job? | 08:33.32 |
| tor8 | norbertj: yeah, something isn't right with the performance on that file | 08:36.04 |
| norbertj | The job is just a bunch of textlines/color rectangles, but with transparancy in it I think. Perhaps the rectangles allocated for transparancy (transparency?) are too big? | 08:36.53 |
| tor8 | it might be that every element causes the transparency device to be pushed and popped, incurring a lot of overhead. I'd have to run through a profiler to be sure though. | 08:37.16 |
| norbertj | tor8: if you know more, can you inform me (and Emeric) ? | 08:38.01 |
| tor8 | norbertj: there's a dirty trick you can do to the xps interpreter: set the environment variable XPS_DISABLE_TRANSPARENCY to anything and it will skip all transparency operations | 08:38.30 |
| | if I do that on this file, it runs in reasonable speed | 08:38.40 |
| norbertj | I know, but we go for quality :( | 08:38.49 |
| tor8 | yeah, I wouldn't recommend that as a "solution", but it does rule out non-transparency related issues | 08:39.17 |
| d3c | Robin_Watts: either my system's memory management is broken or MuPDF's is: http://pastebin.com/raw.php?i=NkJRVidg - I keep getting memory-related problems when running the latest version from the git repo. I can't say that it's not my system, though. what do you think? | 08:48.56 |
| Robin_Watts | d3c: I don't follow. | 09:28.01 |
| | How much RAM do you have in your machine? It could just be that you're running out of memory, given the silly resolutions you're running at. | 09:29.22 |
| d3c | Robin_Watts: sorry, 1.7G so you're probably right. | 09:36.19 |
| tor8 | Robin_Watts: this is an odd problem... the presence or absence of a sibling <Canvas> element provokes the disappearance of the contents of a pattern that uses the transparency device... | 09:53.13 |
| Robin_Watts | xps? | 09:53.32 |
| | in muxps or gs ? | 09:53.39 |
| tor8 | ghostxps, I'm working on bug 692513 and my proposed fix causes regressions in other files | 09:54.08 |
| | the only real change is gspat.uses_transparency being set, but that change makes things vanish :( | 09:55.12 |
| Robin_Watts | tor8: could it be related to the thing that I ran into, and ray is looking into ? | 09:55.17 |
| | to do with smask handling? | 09:55.32 |
| | probably not, I guess. | 09:55.38 |
| tor8 | it's certainly smask related in some way | 09:56.05 |
| | I have isolated it to two 'tests' in fts_04xx | 09:56.30 |
| | the presence of test 0402 makes test 0403 disappear | 09:56.46 |
| | swap the order, they both show | 09:56.54 |
| | remove the soft mask from 0402 makes 0403 show | 09:57.04 |
| Robin_Watts | There is a problem with gs' handling of smasks. | 09:57.19 |
| | In particular, if you change to having smask2 after having smask1, then while smask2 is being drawn, smask1 is still in effect. | 09:57.50 |
| | That doesn't actually have any ill effects, unless smask2 uses a transparency group itself. | 09:58.17 |
| tor8 | that sounds likely, the opacity mask in test 0402 is a gradient with alpha | 09:58.45 |
| Robin_Watts | so you can join me in saying "are you done yet?" to ray in an irritating manner later. | 09:59.19 |
| tor8 | Robin_Watts: http://ghostscript.com/~tor/stuff/0001-Move-the-has_transparency-flag-into-the-xps-context.patch and http://ghostscript.com/~tor/stuff/fts04_stripped.xps if you want to play | 10:00.22 |
| Robin_Watts | tor8: maybe later - am about to go for a run. | 10:00.50 |
| | I pushed my stuff last night, and then realised I'd missed some things you said to do. | 10:01.13 |
| | so they went in in a followup. | 10:01.22 |
| | we now don't try/catch around ever call to pdf_run_keyword. | 10:01.37 |
| | I spent some time being very confused by the output of sane. | 10:01.51 |
| | For the text diffs you display "old/new". For the image diffs you display "new/diff/old" | 10:02.10 |
| tor8 | I've spent time being confused about bmpcmp today | 10:02.14 |
| | really? I thought I displayed old/diff/new | 10:02.25 |
| Robin_Watts | not afaict. | 10:02.35 |
| tor8 | the javascript mouseovers are confusing (or buggy, don't work on chrome) | 10:02.38 |
| Robin_Watts | The javascript mouseovers do indeed have problems with chrome (and firefox, but only on windows). I'm not convinced it's a bug in the js so much as a bug in chromes js, but... | 10:03.37 |
| | And it's only the middle one that doesn't work in chrome, right? the zoom one? | 10:03.58 |
| tor8 | in sane-diff.py I print old/diff/new unless the code gets it wrong which is old and which is new | 10:04.04 |
| | the middle one doesn't work, correct | 10:04.23 |
| Robin_Watts | I checked some md5's and the new one was definitely on the left. | 10:04.38 |
| tor8 | and the mouseover has a tooltip "candidate - reference" but since it swaps them at the same time I'm not sure which is which | 10:04.55 |
| Robin_Watts | but maybe my sane is out of date. | 10:05.00 |
| | Left = candidate, unless you have the mouse in it. | 10:05.20 |
| tor8 | Robin_Watts: it may depend on how you invoke sane, if you run a manual diff the order will depend on the arguments | 10:05.58 |
| Robin_Watts | ../sane/sane.h | 10:06.09 |
| tor8 | then it should be old/diff/new anything else is a serious bug :/ | 10:06.28 |
| Robin_Watts | I'll grab a new version later. | 10:07.05 |
| tor8 | don't trust the file stamps, the renders are cached | 10:07.17 |
| Robin_Watts | I was considering adding 1 pixel borders to the bmpcmo output. | 10:07.19 |
| | cyan for candidate, red for reference. | 10:07.29 |
| | and having them swapped as well. | 10:07.34 |
| | Time to run. bbs. | 10:08.29 |
| | D'oh. can't run yet, have to wait for cleaners. | 10:11.44 |
| chrisl | Robin_Watts: should Acrobat2Tiff have dll and exe files in it? | 10:12.07 |
| Robin_Watts | urm... | 10:12.50 |
| | unless I checked in a built version, no. | 10:13.22 |
| chrisl | Okay, could you check - it looks like you did commit a built version | 10:13.44 |
| Robin_Watts | where did I commit then? | 10:16.02 |
| chrisl | ghostpdl/tools/Acrobat2Tiff | 10:16.44 |
| Robin_Watts | I see no built versions. | 10:17.10 |
| | oh, sorry, yes I do. | 10:17.25 |
| | They are tiny. | 10:17.51 |
| | so maybe it was deliberate. | 10:18.15 |
| | OK. I really am going running now. | 10:18.23 |
| chrisl | I did wonder if it was deliberate, as a convenience | 10:18.33 |
| Robin_Watts | tor8: Ok, so I have a sane report here from 1.0.34 to 1.0.39 | 12:07.22 |
| | <div class="changed"><img src="../png/c5198f..."><img src="../png/c5198f...-886b8...><img src="../png/886b8..."> | 12:08.40 |
| | sane/log/1.0.39-.../blah.pdf.log contains | 12:10.02 |
| | page /path/blah.pdf 1 c51198f | 12:10.41 |
| | oh. | 12:11.38 |
| | but so does 1.0.34-..../blah.pdf.log | 12:11.52 |
| | tor8: OK, how can i completely wipe my sane history and retest from scratch? | 12:12.32 |
| | OK, a complete reset of sane, and it seems to be working OK. Something must have gotten confused. | 12:33.37 |
| d3c | Robin_Watts: this might be a stupid question but if I need to generate a e.g. 1600x1200 px image, wouldn't I need to load the PDF at a resolution of 1600x1200? | 12:49.25 |
| | Robin_Watts: (on screen) | 12:49.47 |
| kens | o | 12:49.54 |
| Robin_Watts | d3c: no. | 12:50.06 |
| | Resolution is dots per inch. | 12:50.20 |
| | screen resolution is typically around 96dpi (higher for some things, like retina displays etc of course). | 12:50.42 |
| | If you want to produce a 1600x1200 image, then use: mudraw -w1600 -h1200 -o out.png input.pdf | 12:51.38 |
| tor8 | Robin_Watts: zap the log directory | 12:51.58 |
| d3c | Robin_Watts: will try that, thanks! | 12:52.42 |
| Robin_Watts | If you set the resolution to 1600x1200, and then render an A4 pdf, you'll actually be producing an image much much bigger. | 12:52.47 |
| | d3c: The command I gave above will produce an image that "fits" into 1600x1200 without ruining the aspect ratio. | 12:53.14 |
| d3c | Robin_Watts: great, that's also what I'm looking for. will give it a try | 12:55.48 |
| Robin_Watts | tor8: ping | 14:03.59 |
| | I've just pushed a patch to my casper repo for your consideration. | 14:04.20 |
| tor8 | Robin_Watts: okay. | 14:19.45 |
| Robin_Watts | when you've had a look, I've found a case it doesn't cope with. | 14:22.26 |
| tor8 | pray tell | 14:24.33 |
| Robin_Watts | In fz_render_glyph, if the font is too large, we warn and return. | 14:24.51 |
| | that should count as a render error. | 14:25.00 |
| tor8 | actually, I'd like to try something else for that -- fall back to rendering it as a path | 14:25.21 |
| Robin_Watts | That would be ideal. | 14:25.34 |
| tor8 | or clip the glyph render to the scissor area and bypass the cache | 14:25.44 |
| Robin_Watts | Ok, so I'll ignore that case. | 14:25.54 |
| | in which case, the patch is good to go I reckon. | 14:26.06 |
| tor8 | yes, lgtm | 14:26.12 |
| | meeting in 30? | 14:27.27 |
| Robin_Watts | yes, I believe so. | 14:27.36 |
| henrys | sigh ... air quality alert | 14:42.22 |
| Robin_Watts | beans for breakfast? | 14:50.45 |
| henrys | http://www.denverpost.com/popular/ci_20835630 | 14:51.25 |
| | really big fire and 0 containment so far. | 14:52.10 |
| Robin_Watts | Anywhere near you? | 14:52.40 |
| paulgardiner | You need our rain. We have plenty to spare. | 14:52.51 |
| Robin_Watts | paulgardiner: But we're still under a hosepipe ban. | 14:53.07 |
| henrys | about 30 miles northwest of me we are covered in haze. | 14:53.22 |
| Robin_Watts | henrys: I have no experience of how far or fast these things spread; I'd imagine 30 miles means you get haze, but you're probably safe from being burnt alive at your keyboard? | 14:54.08 |
| paulgardiner | Worrying though, I should imagine. Does staying indoors really protect you? | 14:55.50 |
| henrys | the fires generally stay in the mountains. I'm not at risk just the air quiality sucks. | 14:55.55 |
| Robin_Watts | so no running? | 14:56.25 |
| henrys | paulgardiner:definitely indoors with a filtered ac on is the way to go, if you can. | 14:56.47 |
| paulgardiner | ah right. | 14:56.55 |
| henrys | yes running and bikiing is cancelled. I'll have to work, crap ;-) | 14:57.23 |
| paulgardiner | :-) | 14:58.38 |
| henrys | great job breaking down the tasks that helps a lot. | 14:58.56 |
| paulgardiner | It's a start. I think some will break down further as we look into them. | 14:59.23 |
| | I have all the scaling all sorted now for the multiline text widget appearance synthesis, I believe. Just committed to casper a few minutes ago. | 15:00.28 |
| henrys | tor8, ready? | 15:00.32 |
| Robin_Watts | paulgardiner: Nice. | 15:00.42 |
| tor8 | yes | 15:01.24 |
| Robin_Watts | What is combed text? | 15:02.33 |
| | I've heard it mentioned several times, but have failed to twig what it is. | 15:03.07 |
| paulgardiner | Test that fits in predefined boxes of equal size. I think it should be easy | 15:03.09 |
| | s/Test/Text/ | 15:03.18 |
| henrys | tor8:how is the improved viewer coming along? | 15:03.53 |
| Robin_Watts | so a pin number 1234, might appear as [1] [2] [3] [4] ? | 15:03.54 |
| paulgardiner | Robin_Watts: yep. I think so. | 15:04.09 |
| tor8 | henrys: basic functionality is there for gtk, still needs search and links | 15:04.33 |
| henrys | we were talking about reducing the schedule by giving stuff to tor8, are any of these items 1-9 good candidates to do with the viewer? | 15:04.39 |
| paulgardiner | Choice widgets may turn out to be more app work than library work. | 15:05.27 |
| henrys | tor8, can you take that one on? | 15:06.43 |
| Robin_Watts | The extra work for saving that I mailed about is separable (but it doesn't really fit into the 'viewer' category either) | 15:06.57 |
| paulgardiner | Text widget constraints too to some degree: the library just needs to return flags. | 15:07.03 |
| | Robin_Watts: I wondered if the nature of the changes I have to make for forms might mean saving being closer to working than we think | 15:08.02 |
| tor8 | so, add widgets to the viewer with some form of callback/other interface to the interactive code? | 15:08.29 |
| paulgardiner | Mostly I overwrite existing stream without any sort of renumbering. | 15:08.31 |
| Robin_Watts | paulgardiner: If we're saving unlinearised (and not removing pages etc), then there will be no renumbering, and we might be pretty well set. | 15:08.56 |
| paulgardiner | tor8: I was thinking for the first version we might handle only static constraints like max chars, digits only etc. | 15:09.46 |
| | tor8: we also need to create the appropriate type of dialog determined by whether multilne or not. | 15:10.47 |
| henrys | this is not specific to paulgardiner's work but how is say 200 dpi resolution working in mupdf? Apple might very well be setting a new standard with the retina displays. And we may be underperforming without hw accleration. | 15:11.30 |
| paulgardiner | Robin_Watts: Good. That's what I wondered. | 15:11.34 |
| Robin_Watts | henrys: At the moment, the big issue with ramping up the resolution is that the glyph bitmaps have a maximum size. | 15:12.36 |
| | IF we go over 1024 pixels we give up and don't render them - we were talking about this about an hour ago. | 15:13.03 |
| | The plan is for us to add some code to get the outline from freetype and to drop back to a path rendering. | 15:13.29 |
| | In terms of overall performance at high resolutions, I think render speed is pretty much a linear scale by number of pixels. | 15:14.08 |
| | (but that's not based on any measurements) | 15:14.57 |
| | At the moment, we only decode images in their entirety (no strip based decode), and we scale the whole image for interpolation. | 15:16.02 |
| henrys | Robin_Watts:and you expressed some interest in doing item 9? | 15:16.31 |
| Robin_Watts | so rendering interpolated images at high resolution may hit memory limits. | 15:16.53 |
| | Item 9: testing, yes. | 15:17.01 |
| | well, testing yes, not necessarily exactly item 9. | 15:17.34 |
| henrys | okay | 15:18.15 |
| Robin_Watts | Doing partial image decode within mupdf is a bigger job that requires a revised interface between the mupdf core and the image decoder libs. | 15:18.43 |
| | (tor8, have I misrepresented anything that you can think of?) | 15:19.01 |
| henrys | skipping around subject wise is text AA still needed at these high resolutions? | 15:19.03 |
| Robin_Watts | Possibly not, but it doesn't cost us much (if anything). | 15:19.41 |
| tor8 | Robin_Watts: we don't scale images up, only down, IIRC | 15:19.46 |
| Robin_Watts | tor8: Ah, that's true. So the issue with image size exploding at high res probably goes away. | 15:20.17 |
| tor8 | yeah. I think algorithmically we should be nearly linear with the number of pixels, but then you've got cache misses to worry about with large pixmap buffers | 15:20.53 |
| henrys | paulgardiner:so 8 looks like the big problem. | 15:20.59 |
| | at least the one that doesn't look very straightforward. | 15:21.24 |
| paulgardiner | The test shouldn't be a big problem, but the test might uncover a big problem. | 15:21.50 |
| | When I looked over files by eye I got the impression that people do little with javascript. | 15:22.45 |
| | On the other hand, covering the whole DOM could take ages. | 15:23.17 |
| | I think it was Robin's idea that we should just scan our test files for the top level DOM object. We might find most completely unused. | 15:24.18 |
| | s/object/objects. | 15:24.35 |
| henrys | yea my concern is we could get a customer that requires "coverage" and doesn't focus on "usage" | 15:24.40 |
| Robin_Watts | Well, at that point we ask them to provide us with coverage tests and develop to that. | 15:25.15 |
| d3c | Robin_Watts: good job with the bugs. is the "malloc of array failed" the error you're describing in http://bugs.ghostscript.com/show_bug.cgi?id=693114 ? | 15:26.08 |
| henrys | paulgardiner:I didn't have anything else for the meeting it looks like things are proceeding nicely, unless we want to go through each item, I don't think that necessary. | 15:27.05 |
| Robin_Watts | d3c: Failing to render because we can't malloc a large enough buffer is not a bug, as long as we correctly return an error code, and we do now. | 15:27.09 |
| henrys | Robin_Watts, tor8:more for the forms meeting? | 15:27.21 |
| Robin_Watts | Not from me. | 15:27.27 |
| henrys | so we agree you guys Robin_Watts, and tor8 will chip away on a couple of the items as discussed? | 15:27.56 |
| Robin_Watts | d3c: failing to render because we have an internal 4Gig limit to bitmap size *is* arguably a bug, but not one we are going to worry about for now. | 15:27.56 |
| tor8 | not from me. I'll bug paul about how to integrate widgets in the viewer. | 15:28.03 |
| paulgardiner | I'm happy. Some time I'd like to get the end of my casper master branch committed to the main repo | 15:28.12 |
| Robin_Watts | henrys: OK. | 15:28.20 |
| paulgardiner | ... probably needs another rebase, but it's only 4 commits I think. | 15:28.52 |
| henrys | great let's call the meeting done for this week. | 15:28.57 |
| d3c | Robin_Watts: oh. I didn't realize that was the case - so it simply means mu can't get enough memory to perform the operation? | 15:29.10 |
| Robin_Watts | d3c: There *is* a bug at the moment, whereby if we fail to render glyphs because they are too large, that isn't reflected in the return code. That is what bug 693114 is about. | 15:29.13 |
| | d3c: yes. | 15:29.29 |
| | "malloc of array failed" = we couldn't get enough information. | 15:29.41 |
| paulgardiner | 4:30. That's good: I can hang about and see what else is going on. | 15:29.54 |
| Robin_Watts | unless you see "malloc of array failed (integer overflow)" in which case it's because of the internal 4gig limit. | 15:30.03 |
| d3c | Robin_Watts: great then - what you said about using -w and -h solved everything for me. no more memory problems. | 15:30.03 |
| Robin_Watts | d3c:Fab. | 15:30.13 |
| | d3c:Thanks for the reports. | 15:30.22 |
| d3c | Robin_Watts: no problem, thanks for the fixes ;) | 15:30.29 |
| kens | henrys ping | 15:35.29 |
| henrys | yes I'm answering it. | 15:36.01 |
| kens | Ah, thanks :_) | 15:36.07 |
| | Just wanted to ask if you would look at it | 15:36.15 |
| henrys | see if that works. | 15:37.56 |
| d3c | Robin_Watts: should `make build=release` run without any warnings whatsoever? | 15:41.12 |
| Robin_Watts | That's what we aim for, but we don't always make it. What are you seeing? | 15:41.43 |
| d3c | Robin_Watts: http://pastebin.com/raw.php?i=8qUbbBhC (x86_64) | 15:42.22 |
| Robin_Watts | ok, anything in 'ft' and 'jbig2' we can ignore. | 15:43.18 |
| | "may be used uninitialised" = "Compiler is too stupid to get the test right" generally. | 15:43.48 |
| d3c | Robin_Watts: ok, no issues then. thanks | 15:44.47 |
| Robin_Watts | and I think that's everything, right? | 15:44.48 |
| | np. | 15:44.51 |
| d3c | Robin_Watts: yeah | 15:44.51 |
| Robin_Watts | tor8, paulgardiner: before the next meeting starts... paulgardiner said that he wanted to get the forms stuff committed into the main repo. | 15:49.22 |
| | Are we planning on doing that on a branch, or on master? | 15:49.37 |
| | and presumably we want to keep the history rather than flattening it all to a single commit ? | 15:50.09 |
| paulgardiner | The stuff I was refering to probably makes most sense on master. Some of it is android changes. | 15:50.33 |
| Robin_Watts | right, sorry, I was misunderstanding. | 15:51.41 |
| paulgardiner | It's the last four commits to master on my casper repo. I'd imagine we at least want the two android ones. | 15:52.48 |
| Robin_Watts | yes, I see now. Let me look at them now. | 15:53.00 |
| paulgardiner | I can rebase them if we decide we want to go ahead. | 15:53.45 |
| tor8 | paulgardiner: I thought you had some other changes too, with the pdf_obj stuff? | 15:54.13 |
| Robin_Watts | I'm cherry-picking them into master here. | 15:54.23 |
| paulgardiner | tor8: Yeah that's one of the four. | 15:55.03 |
| | tor8: although that one you may or may not want. | 15:55.16 |
| tor8 | right you are, I'm blind today | 15:55.22 |
| | paulgardiner: what's the purpose for pdf_get_stream? | 15:58.36 |
| henrys | next meeting... | 15:59.51 |
| | chrisl:let's talk about changing every file in the tree, yeah! | 16:00.12 |
| Robin_Watts | No ray. Are we expecting him? | 16:00.24 |
| henrys | oh yes we are expecting him. | 16:00.52 |
| chrisl | henrys: I just realised I'd made a mistake in my script - it'll be tomorrow before I get the file headers finished | 16:01.05 |
| henrys | no mistakes allowed in ths commit ;-) | 16:01.38 |
| | let's just go on and see if ray shows up. | 16:02.14 |
| chrisl | Yes, just a scripting typo, in this case, but it messed up some of the source files..... | 16:02.20 |
| henrys | alexcher, anything on the mupdf parser? | 16:02.33 |
| chrisl | henrys: I'd also like to remove the (now pointless) $Id$ comment | 16:02.47 |
| henrys | chrisl:makes sense to me. | 16:03.01 |
| Robin_Watts | chrisl: sounds sensible. | 16:03.05 |
| alexcher | henrys: Not yet but I'm continue to work. | 16:03.10 |
| henrys | also we are going to integrate gsprint and redmon into the gs release. If anyone has opinions on this, weigh in. | 16:03.45 |
| alexcher | henrys: I can now show some of the image types. | 16:03.52 |
| paulgardiner | tor8: Hmmm. I'll catch you tomorrow. | 16:04.09 |
| Robin_Watts | henrys: Are they going to live in ghostpdl ? | 16:04.19 |
| chrisl | henrys: Oh, yeh: any idea where I can get gsprint? the wisc mirror has been taken down..... | 16:04.31 |
| henrys | ghostpdl or gs | 16:05.15 |
| | chrisl:I was just looking at it yesterday | 16:05.43 |
| chrisl | henrys: the *pages* are still there, the actual downloads are gone | 16:06.05 |
| Robin_Watts | Playing devils advocate here, what's the advantage in rolling them into ghostpdl (or gs) versus having their own git repos, and releasing in sync? | 16:06.38 |
| henrys | http://pages.cs.wisc.edu/~ghost/gsview/get49.htm | 16:06.43 |
| Robin_Watts | Do they share libs or source? | 16:06.51 |
| chrisl | henrys: if I use the download links on that page, it just times out | 16:07.19 |
| henrys | yes I see... | 16:07.29 |
| Robin_Watts | That's gsview, not gsprint. | 16:07.50 |
| | http://fossies.org/unix/misc/ghost/ghostgum/gsv49src.zip/ ? | 16:08.29 |
| chrisl | Russell mentioned a while back that they'd just removed the download mirrors - no warning, or anything. I thought he was going to talk to you about us hosting those files | 16:08.29 |
| henrys | this works http://pages.cs.wisc.edu/~ghost/gsview/get50.htm | 16:08.44 |
| Robin_Watts | oh, gsprint is part of gsview, sorry. | 16:09.25 |
| henrys | well step 1 is to separate them. | 16:09.40 |
| chrisl | Git it, thanks - I guess Russell took my suggestion about moving the files around...... | 16:09.55 |
| henrys | we can't distribute gsview but we have a request for gsprint | 16:09.58 |
| chrisl | s/Git/Got | 16:10.03 |
| Robin_Watts | Go they share libs or src with ghostscript/ghostpdl ? | 16:10.11 |
| | s/Go/Do/ | 16:10.15 |
| kens | Gsview uses GS | 16:10.26 |
| Robin_Watts | kens: Right, but at "arms length", right? | 16:10.40 |
| kens | Pretty much, yes | 16:10.51 |
| | You can point it at any GS installation | 16:10.59 |
| chrisl | GSView uses the GS API through a dll | 16:11.00 |
| henrys | russell has permission if you are concerned about GPL infringement. | 16:11.27 |
| Robin_Watts | If gsprint requires headers or code from gs when building, then it's a clear decision to put them into the same git repo. | 16:11.51 |
| henrys | we are changing everything in gsprint to GPL license and making it ours. | 16:12.16 |
| Robin_Watts | If not... what do we gain from rolling the two together? Why needlessly conflate the two? | 16:12.29 |
| henrys | and leaviing gsview alone, hopefully that is possible. | 16:12.34 |
| Robin_Watts | The license is not the issue. | 16:12.38 |
| henrys | I was thinking we should have an apps directory in gs and this could be our first program, but I'm not sure, what do you guys think? | 16:14.16 |
| chrisl | As Robin_Watts says, I think depends on how gsprint uses Ghostscript | 16:14.48 |
| henrys | well it's ours now we can set it up as we please. | 16:15.34 |
| Robin_Watts | If gsprint requires headers from gs when building, then having it inside an apps directory makes sense. | 16:15.39 |
| kens | Well it uses the GS API | 16:15.56 |
| henrys | it has to use the api header right? | 16:16.13 |
| kens | So presumably it uses gs_api,h at least | 16:16.14 |
| Robin_Watts | kens: yes. does it have it's own copy of that? | 16:16.29 |
| kens | I would imagine it must yes | 16:16.42 |
| henrys | anyway maybe chrisl can have a quick study of the code and that will make the decisions easier. | 16:16.55 |
| kens | because it can be opinted at any GS DLL | 16:16.55 |
| Robin_Watts | Then it doesn't need to be within the same source tree (unless we want to change that). but yes, a decision for chrisl. | 16:17.23 |
| henrys | the other thing for the meeting is just a reminder about a few new bugs I noticed in bug aging. Everyone is watching that I assume. | 16:18.16 |
| chrisl | Hmm, there doesn't seem to be any separation in the source tree between gsview and gsprint :-( | 16:18.41 |
| kens | I'm watching bug aging yes | 16:19.04 |
| | I don't think I have nay open customer ones | 16:19.12 |
| henrys | tor8:the fts_0512.xps enhancement? | 16:19.15 |
| Robin_Watts | My customer bug is held up on the changes that ray is making to the pdf interpreter for me (hence me noticing that he's not here to ask about it) | 16:19.27 |
| henrys | I know he's got critical customer issues is that something alexcher could do? | 16:20.05 |
| Robin_Watts | possibly. | 16:20.20 |
| tor8 | henrys: I've got a patch for it, but that's run into other regressions that may be related to the smask issues ray and robin have been looking at | 16:20.44 |
| alexcher | Which bug numbers? | 16:20.45 |
| tor8 | 692513 | 16:21.02 |
| henrys | alexcher probably wants Robin_Watts bug. | 16:22.24 |
| Robin_Watts | alexcher: The change that ray is looking into for me is as a result of 692870, but the details of the change I have requested from ray are not on that bug. | 16:22.29 |
| | We had a huge discussion on here the other day between myself, michael and ray, and hammered out the way to go. | 16:22.50 |
| | I can open a new bug with details of the required change on if that makes it easier. | 16:23.10 |
| henrys | so irc logs could tell alexcher everything. | 16:23.18 |
| Robin_Watts | henrys: yes, the logs contain all the information, but possibly not in the most easily comprehended form. | 16:23.43 |
| | Michael, Ray and I were all arguing from slightly different places and it took a while for us to reach common ground. Reading the logs is likely to be confusing. | 16:24.20 |
| henrys | Robin_Watts:I think it is safe to assume alexcher can get to it sooner than ray so whatever we need to do for that would be good. | 16:24.23 |
| alexcher | henrys: OK | 16:24.36 |
| Robin_Watts | OK. I'll prepare a new bug with the details on for alex then. | 16:24.45 |
| henrys | great | 16:24.55 |
| | 9:25 five minute early finish, okay? | 16:25.33 |
| kens | Sounds good to me :) | 16:25.55 |
| alexcher | henrys: GS has a problem with PDF patterns. | 16:26.12 |
| henrys | tor8:btw port install mupdf fails - openjpg incompatible | 16:26.29 |
| alexcher | henrys: Neither TilingType 1 or 2 match Acrobat. | 16:26.36 |
| henrys | alexcher:which bug? | 16:26.37 |
| | do they match the spec? | 16:26.54 |
| Robin_Watts | henrys: You want to be complaining to the port maintainer, not us :) | 16:27.07 |
| tor8 | henrys: there's a bug for that, 693010 | 16:27.15 |
| alexcher | 692503 | 16:27.39 |
| | | 16:27.41 |
| kens | Off ro now | 16:28.18 |
| henrys | Robin_Watts:okay I will report it. | 16:28.20 |
| kens | for now* | 16:28.22 |
| henrys | if one of you haven't already. | 16:28.31 |
| | tor8's bug is debian not mac. | 16:28.44 |
| tor8 | henrys: likely same issue | 16:28.59 |
| Robin_Watts | I don't use port on the mac. I think I use fink. | 16:28.59 |
| henrys | alexcher:are you sure the origin doesn't correspond to the device space origin? | 16:31.10 |
| | for example in acrobat reader 0,0 (device) is in the center. | 16:31.33 |
| chrisl | PDF patterns are supposed to anchor to the page origin | 16:32.22 |
| henrys | alexcher:until we have a customer trip over this I'd say we have bigger problems. How does mupdf handle the file? | 16:32.28 |
| alexcher | Using TilingType 2 matches Acrobat but creates artifacts in some patterns. | 16:32.38 |
| | I didn't try current mupdf. Linyx Document Viewer works fine. | 16:35.24 |
| henrys | so the bug should be open but it isn't high priority. It is a real company that reported it, so it should go to scott for a support contract. | 16:37.12 |
| | alexcher:okay? | 16:37.37 |
| alexcher | OK, I'm reopening the bugs. | 16:37.57 |
| | gs matches the spec but not Acrobat. | 16:38.19 |
| henrys | well if they want to pay us maybe we can emulate acrobat. | 16:38.52 |
| chrisl | alexcher: that sounds pretty much identical to an issue I investigated for cust 532: I found some really weird rounding going on when we work out the bbox and step of a type 1 pattern - I couldn't get a solution to it, though | 16:39.46 |
| alexcher | chrisl: even if we do perfect rounding, the error will accumulate. | 16:41.08 |
| henrys | are you using clist patterns? Does it change if the maxbitmappattern is large enough to bypass clist? | 16:41.09 |
| alexcher | henrys: no. The difference is visible on x11 device. | 16:42.04 |
| chrisl | alexcher: yeh - if we rounded "accurately" we got gaps between the tiles at certain resolution, with the current scheme, the stepping doesn't match Acrobat. | 16:42.37 |
| henrys | if the pattern is large enough the clist patterns will be used I believe. | 16:42.41 |
| chrisl | if this is the same issue I looked at for 532, clist vs bitmap should have no effect | 16:43.15 |
| henrys | chrisl:do you want to study this one a bit, assign it to you? | 16:43.50 |
| chrisl | henrys: it will be a while before I can get to it, but I'll add myself to the cc list and "co-own" it with alexcher for now | 16:45.05 |
| henrys | okay | 16:45.22 |
| alexcher | henrys: How important is support of big objects in PDF interpreter? | 16:46.30 |
| | henrys: We have a P2 bug about it. | 16:46.52 |
| henrys | one of the things that will go away with the mupdf parser, yes? | 16:48.41 |
| Robin_Watts | henrys: Surely not. The parser might read the pattern details out differently, but the graphics lib that will render it will be the same. | 16:49.27 |
| | oh, sorry, large objects. Ignore me. | 16:49.47 |
| henrys | and don't call me shirley | 16:51.55 |
| alexcher | henrys: Yes, it will. Should I consider mupdf parser as a fix for gs problems? | 16:52.06 |
| henrys | which bug is this? | 16:52.28 |
| alexcher | 693111 | 16:52.46 |
| henrys | I think mupdf integration should have higher priority than non customer bugs usually. | 16:53.16 |
| alexcher | 693111 is customer's 384. | 16:54.13 |
| | We also have P4 bug 693101. | 16:55.01 |
| henrys | hmm I can try and push back on 384 as an enhancement. | 16:56.17 |
| | alexcher:no quick workaround for that is there? | 16:56.33 |
| alexcher | henrys: I can hack the array reading procedure and try to recreate the page tree for the P4 bug. | 17:00.12 |
| | henrys: I don't see how to deal with big strings. | 17:00.35 |
| henrys | If you want to verify it will work with the mupdf parser, update the bug with a schedule for the parser 6 months? I'll push back to the customer as an enhancement. What could possible go wrong ;-)? | 17:01.10 |
| Robin_Watts | alexcher: I have created bug 693115 with the best description I can manage of the problem. Please let me know if it's unclear. | 17:01.34 |
| henrys | alexcher ^^^^^ | 17:01.35 |
| Robin_Watts | Hi ray_work. | 17:01.45 |
| | ray_work: We discussed the PDF interpreter SMask changes at the meeting in your absence, and it was felt that you probably have more than enough customer work on your plate, so we should pass it off to alexcher to do. | 17:03.07 |
| alexcher | Robin_Watts: I'll post a comment if something is not clear to me. | 17:03.20 |
| henrys | tor8:I selfupdated my port (whatever that means) and now mupdf installs and works. | 17:03.57 |
| Robin_Watts | So I've created bug 693115 with a description on. (unless you've already gotten it done?) | 17:04.01 |
| | alexcher: Fab, thanks. | 17:04.12 |
| chrisl | henrys: now you're one of those annoying users who insists on using unsupported third party libraries! | 17:04.48 |
| ray_work | Robin_Watts: are you going to add your test file to that bug. | 17:06.39 |
| Robin_Watts | just about to. | 17:06.46 |
| ray_work | Robin_Watts: I was sort of putting it off (and working on other stuff) while hoping that you could create a test file that actually showed a difference compared to Adobe | 17:07.54 |
| Robin_Watts | I get a really obvious difference when I use my/michaels patch from the parent bug. | 17:08.40 |
| | but trying to make a file that shows the bug now is likely going to drive me potty. | 17:09.24 |
| ray_work | alexcher: I added myself to the CC on that bug in case something isn't clear so if you post a comment I will make sure and see it | 17:09.34 |
| henrys | chrisl:yes I guess I am, installing a package is convenient though. | 17:10.01 |
| ray_work | Robin_Watts: OK, so maybe alexcher should have that patch so he can see the difference | 17:10.26 |
| chrisl | henrys: that's no excuse - neither Robin_Watts nor tor8 will accept any bug or feature request from you now ;-) | 17:10.52 |
| Robin_Watts | ray_work: Possibly, but I won't promise that that patch is bug free, currently. | 17:10.58 |
| ray_work | Robin_Watts: of course (caveat emptor) | 17:11.16 |
| henrys | chrisl:so nothing's changed ;-) | 17:12.09 |
| chrisl | :-) | 17:12.15 |
| alexcher | pay_work: please attach the patch to the corresponding bug report, whatever it is. | 17:13.03 |
| Robin_Watts | alexcher: it's my patch, and I will do so (unless I can come up with an example that shows the problem without the patch) | 17:13.57 |
| | but when debugging, you don't need the patch to see that something is wrong, because it repeatedly renders an smask when it doesn't need to. | 17:14.46 |
| mvrhel_laptop | Scott and I got the booth set up this morning | 17:36.31 |
| Robin_Watts | Hi mvrhel_laptop | 17:37.14 |
| mvrhel_laptop | hi Robin_Watts | 17:37.26 |
| Robin_Watts | ray_work, alexcher: I succeeded in making an example that shows a rendering difference without my patch, and I've attached it to the bug. | 17:37.39 |
| | mvrhel_laptop: good flight etc? | 17:37.56 |
| mvrhel_laptop | yes no problems. | 17:38.07 |
| Robin_Watts | mvrhel_laptop: Has Scott tried to give you a couple of dogs yet? | 17:38.14 |
| mvrhel_laptop | hehe I think they are coming your way | 17:38.26 |
| henrys | howdy mvrhel_laptop | 17:38.45 |
| mvrhel_laptop | hi henrys | 17:38.51 |
| Robin_Watts | Alas, we're full. And you have no idea how much it costs to get dogs into this country - 6 months of kennel fees, because of the rabies quarantine. | 17:39.06 |
| mvrhel_laptop | wow | 17:39.18 |
| henrys | mvrhel_laptop:do you have wireless at the show? | 17:45.52 |
| mvrhel_laptop | henrys: good question. I did not check into that when we set up | 17:47.24 |
| | I am at the hotel now. | 17:47.31 |
| | Scott and I are going to do a bit of sight seeing in about 15 minutes | 17:47.46 |
| | show starts tomorrow | 17:47.58 |
| henrys | if so we should set up skype and you guys could leave, we'll take turns. | 17:48.41 |
| mvrhel_laptop | :) | 17:48.57 |
| ray_work | Robin_Watts: thanks for the modified file | 17:55.08 |
| Robin_Watts | mvrhel_laptop: What are you going to go sightsee? | 17:56.08 |
| | ray_work: You're welcome. Thanks for guilt tripping me into trying for it :) | 17:56.36 |
| mvrhel_laptop | we are still trying to decide. may head down to see what is going on at ground zero. Last time I was in Manhattan was before 2001 | 17:57.00 |
| Robin_Watts | Highlights of new york for me were standing on the Brooklyn Bridge at Sundown, and going up 30 rockerfeller plaza. | 17:57.14 |
| | I missed seeing the Aircraft carrier though - that would have been worth it probably. | 17:57.59 |
| | http://www.intrepidmuseum.org - now with a space shuttle! | 17:58.58 |
| | (oh, but not open for viewing until 19th July) | 17:59.42 |
| mvrhel_laptop | I did see the space shuttle yesterday | 18:00.20 |
| | off to meet scott | 18:00.36 |
| | ttyl | 18:00.39 |
| sebras | Robin_Watts tor8: I have a guy in my inbox that want \b to go to the previous page. | 21:05.40 |
| | currently \b is not bound to anything, so I might as well help him out until the gtk-based viewer is ready. | 21:06.09 |
| | I pushed a patch to sebras/master (which also updates the manpage). | 21:08.46 |
| | and now also the help in pdfapp_usage(). | 21:09.55 |
| | Forward 1 day (to 2012/06/13)>>> | |
IRC Logs