| | <<<Back 1 day (to 2013/10/06) | 2013/10/07 |
| marcosw | internet down for anyone else? | 01:41.19 |
| ray_laptop | marcosw: internet's up for me (and apparently, ghostbot) | 02:54.16 |
| | marcosw: since you can get to IRC, what part of the internet isn't working for you? | 02:54.50 |
| mvrhel_laptop | been beating upon transparency stuff all weekend. a bit further with what appears to be two remaining issues | 05:09.07 |
| marcosw | morning kens | 07:24.59 |
| kens | morning marcosw | 07:25.07 |
| | Your intertubes are OK now ? | 07:25.13 |
| marcosw | yes. it was strange, some internet sites were fine (google.com, ebay.com, ...) and other weren't (cnn.com, apple.com, ....) | 07:25.52 |
| | must have been a routing problem. | 07:26.16 |
| kens | sounds like it yes | 07:26.22 |
| tor7 | Robin_Watts: http://www.opengl.org/registry/specs/NV/blend_equation_advanced.txt hmm, more fun with nvidia cards... | 09:29.23 |
| Robin_Watts | tor7: oh, god... | 10:09.33 |
| tor7 | Robin_Watts: morning. | 10:17.26 |
| Robin_Watts | I just dropped the laptop off at the parcel depot. | 10:17.42 |
| | had trouble trying to post it on friday :( | 10:18.00 |
| tor7 | great! hopefully it'll be here before friday then :) | 10:19.16 |
| Robin_Watts | http://topinfopost.com/2013/10/03/fbi-arrests-29-year-old-mastermind-of-billion-dollar-internet-drug-blackmarket | 10:35.00 |
| | http://ghostscript.com/~robin/out.svg | 12:27.18 |
| | mupdf pdf -> SVG now does text as paths. | 12:27.45 |
| | lunchtime. | 12:28.04 |
| paulgardiner | Coo! Impressive | 12:31.11 |
| tor7 | Robin_Watts: wow! that's neat. | 12:31.17 |
| | renders beatifully (if dog slow...) in firefox | 12:31.28 |
| | paulgardiner: I looked over your ios commits on friday, but I have to confess not grokking some of the new objc syntax that you've used... | 12:35.03 |
| | ^(MuTapResultExternalLink *link) for instance | 12:35.26 |
| paulgardiner | tor7: It's a way to switch over subtypes without using rtti and casting | 12:36.19 |
| tor7 | void (^)(MuTap... *)) -- is that like a function pointer to a block? | 12:36.20 |
| paulgardiner | Yes. Passing a block | 12:37.01 |
| | The purpose can be seen via the use in MuDocumentController.onTap | 12:38.32 |
| tor7 | right, so that's passing three blocks to the switchCaseXXX function, but which one is invoked depends on the object that receives the message? | 12:38.42 |
| paulgardiner | That's it | 12:39.00 |
| tor7 | due to differing implementations of switchCaseX | 12:39.01 |
| | right. seems odd to my brain, but so does most of objc :) | 12:39.13 |
| paulgardiner | Yeah | 12:39.14 |
| tor7 | why does BOOL tapHandled need to be in __block? | 12:40.19 |
| paulgardiner | I think it might be called the "visitor" paradigm. It works out more neatly in Java | 12:40.50 |
| tor7 | patterns. *shudders* | 12:41.45 |
| paulgardiner | In the Obj-C case, it might have been better to make a delegate protocol that MuDocumentController then implements, but then the cases would appear as separate functions and it might be less readable | 12:41.53 |
| | I'm keener to change things like this than you might imagine. I like working on code written in your style, so if you do have suggestions for another way, do say - now, or later if something occurs to you. | 12:45.14 |
| | Also, a lot of the time with obj-C (and Java) I'm experimenting with ideas I've come across. | 12:46.10 |
| tor7 | paulgardiner: I don't mind churn if you want to try different ideas and commit them as you go | 12:46.49 |
| paulgardiner | Yeah, that sounds good to me. | 12:47.13 |
| tor7 | handleTap basically returns the fz_link_dest information wrapped in a MuTapResult | 12:48.04 |
| | are there more tap results you envision, like forms etc? | 12:48.14 |
| paulgardiner | In this particular case, I'm pleased with how the use has come out in MuDocumentController, but less pleased that the implementation in MuTapResult is in one part n-squared in number of cases | 12:48.17 |
| tor7 | I probably would've gone with the dumb approach of having HitView call functions back to the DocumentController rather than returning a value | 12:49.13 |
| | or maybe initialise the HitView with a function callback/block to call on a hit | 12:49.31 |
| paulgardiner | tor7: there will be at least on more result for forms, but that's likely to be a sort of do-nothing-but-consume-tap result, because MuPageViewNormal will do all the real work | 12:49.49 |
| tor7 | remind me, is the hitview a transparent view that sits on top of the pageview and draws transparent rects on top, and eats tap inputs? | 12:50.35 |
| | I wonder how performance is there, if we were to stack multiple HitView (or similar) views | 12:51.01 |
| paulgardiner | tor7: Having HitView call functions back to the DocumentController is very similar to the variant using a delegate protocol. | 12:51.02 |
| | tor7: yeah, that's what HitView is | 12:51.20 |
| tor7 | one HitView per link type, created with a callback (target and objc selector) | 12:51.21 |
| | which is similar to the UIKit/AppKit approach | 12:51.47 |
| | or one HitView with a subobject HitTarget which defines the region and target/selector for an onHit | 12:52.21 |
| | TapTarget array with onTap callbacks | 12:52.47 |
| | (just thinking out loud here, feel free to ignore everything I say) | 12:53.05 |
| kens | likes today's XKCD | 12:53.09 |
| tor7 | kens: :) | 12:54.06 |
| paulgardiner | The target selector approach is certainly a possibility. The downside of that is the lack of type safety. Using a delagate protocol is a sort of half-way between what I have and that | 12:54.45 |
| tor7 | type safety? in objc? mwahahaaa :) | 12:55.00 |
| | well, the lack of type safety is why the objc stuff is all about selectors rather than function pointers | 12:55.40 |
| paulgardiner | :-) | 12:55.41 |
| tor7 | sending a selector to NULL is a no-op, which is pretty neat | 12:56.07 |
| | [nil doStuff]; is fine | 12:56.15 |
| paulgardiner | yeah, but swings and roundabouts because sometimes it hides mistakes | 12:56.51 |
| | Did Obj-C influence mupdf? Some of the nice things in mupdf seem similar to Obj-C | 13:00.02 |
| tor7 | paulgardiner: not consciously, but I did have a bout of infatuation with objc back in the late 90's early 00's | 13:03.20 |
| paulgardiner | Right, but thankfully you recovered! :-) | 13:04.04 |
| Robin_Watts | Looks like there is a "Type-3" like mechanism in SVG for fonts. I should probably use that. | 13:06.45 |
| paulgardiner | tor7: fitPageToScreen confuses me slightly. It's sometimes used to scale from page to iOS units, sometimes to pixels, and it always uses floor. I wonder if we should always calculate to pixels and then adjust afterwards for dots, so that we always apply the same scaling, in effect. | 13:11.32 |
| | Not that anything is behaving wrongly... | 13:12.01 |
| tor7 | Robin_Watts: there are svgfonts and the define/use a symbol mechanism as well | 13:12.31 |
| | paulgardiner: I don't remember any of that, do what you feel is necessary | 13:12.48 |
| paulgardiner | Okay, but I think I'll leave it for now bacause it works and I'm not certain enough I understand it fully | 13:13.28 |
| tor7 | I know I spent some time getting the scaling factors to always fit the rendered page mediabox to the integral number of units/pixels | 13:13.36 |
| | so we don't see white edges when there's an exactly page-sized colored background | 13:13.36 |
| Robin_Watts | tor7: SVGfonts may be what I was talking about. | 13:13.59 |
| paulgardiner | No, I think the only effect would be to make the link rectangles very slightly out. | 13:14.13 |
| Robin_Watts | You can define a font in svg by giving a set of glyph definitions; each glyph can either be a path, or a list of arbitary svg content. | 13:14.31 |
| paulgardiner | ... or not, if my understanding is incorrect. | 13:14.31 |
| tor7 | Robin_Watts: I think SVG fonts would be preferable, if the majority of svg viewers have support for it | 13:14.36 |
| | that'd make text selectable and copy&paste-abel | 13:14.44 |
| Robin_Watts | text is already selectable/copy-pastable I believe. | 13:15.00 |
| tor7 | It didn't work in firefox | 13:15.15 |
| Robin_Watts | I send 0-opacity text. | 13:15.18 |
| | Then I send the paths to draw over it. | 13:15.27 |
| | Using fonts rather than paths would be preferable for size of the documents though. | 13:15.59 |
| | and probably speed of rendering. | 13:16.06 |
| tor7 | Robin_Watts: oh, I can select and copy the text. I just don't get a highlight in firefox. | 13:16.09 |
| | and there are about 90 blank lines between each paragraph... | 13:16.27 |
| | Robin_Watts: yeah. def/use would save on the size, but maybe not on rendering speed | 13:16.56 |
| Robin_Watts | The question is, is what I am thinking of as svgfonts the same as what you are thinking of ? | 13:16.57 |
| | def/use should hopefully help on rendering speed as it can be cached. | 13:17.16 |
| tor7 | Robin_Watts: *if* it's cached, which I'm not convinced they do | 13:17.31 |
| Robin_Watts | The problem with defining a font is that it buggers up my nice simple 'just output to the output file as we go along' way of working. | 13:17.52 |
| | Unless I dump the whole font when we first meet it. | 13:18.09 |
| tor7 | Robin_Watts: right. you could output to separate fz_outputs writing to fz_buffer and join them at the end? | 13:18.20 |
| Robin_Watts | tor7: That's what I think I'll have to do, yes. | 13:18.31 |
| tor7 | which means you could build up a use/def dictionary, and/or svgfonts as you encounter the glyphs | 13:18.55 |
| Robin_Watts | Ah, sorry, maybe we are talking at cross purposes here. | 13:19.34 |
| tor7 | <font><glyph unicode="xxx" d="...">, should let you emit glyphs in any order | 13:19.49 |
| Robin_Watts | If I can define sections that can be reused, then I can safely define them just in time. | 13:20.00 |
| | but as you say, no caching. | 13:20.07 |
| | If I work properly as svg fonts, then I have to define them up front. | 13:20.19 |
| | but they really ought to be cached. | 13:20.26 |
| tor7 | Robin_Watts: my idea would be you write the svg header, then open two fz_output buffers | 13:20.37 |
| | one to accumulate the use/def definitions | 13:20.49 |
| Robin_Watts | tor7: Yeah. | 13:20.57 |
| tor7 | one to write graphics as you encounter them | 13:20.57 |
| | then dump both at the end | 13:21.01 |
| | or if doing svgfont, open a new fz_output buffer for each font, concatenate glyph definitions as you encounter them | 13:21.20 |
| | and write them out before the page content that uses them at the end | 13:21.42 |
| Robin_Watts | tor7: Probably I'd want to make a list of fonts I'd met, and which glyphs from that font had been used. | 13:21.47 |
| | Then write them out. | 13:21.56 |
| | saves me having too many output buffers open at a time. | 13:22.21 |
| tor7 | Robin_Watts: yeah. the question I guess is one of whether to dump all glyphs in a font at first encounter, or build it up on the fly. | 13:22.22 |
| Robin_Watts | BUT the buffers might be quite large. | 13:22.49 |
| | I do wonder if just doing 2 passes through the file would be smarter. | 13:23.02 |
| tor7 | Robin_Watts: recording which fz_font and glyphs are used and creating the svgfont buffer at page end could work | 13:23.37 |
| | you'd only hold the content fz_output buffer in memory | 13:23.45 |
| | the svgfonts could be written directly to disk | 13:23.53 |
| | before you write out the page contents | 13:24.04 |
| Robin_Watts | How about a 2 pass system where you run the page(s) twice. Which we can then wrap into a single pass system by having it write to a list internally, then play the list back twice? | 13:24.55 |
| tor7 | what would you gain by having 2 passes? | 13:25.13 |
| | one to just collect the font statistics, and one to write the content? | 13:25.24 |
| Robin_Watts | tor7: First pass calculates what fonts are needed etc. | 13:25.28 |
| | second pass, yes. | 13:25.31 |
| tor7 | the pdfwrite way would be to write to temp files | 13:25.44 |
| | but I'd rather not get into that mess | 13:25.51 |
| Robin_Watts | tor7: indeed, but we have avoided that so far. | 13:25.58 |
| tor7 | I wonder, where are the <font> definitions allowed? | 13:26.23 |
| | must they all be up front or can the appear in the middle of the document | 13:26.33 |
| Robin_Watts | <font> definitions are allowed at any point. | 13:26.33 |
| | good style is to have them up front. | 13:26.45 |
| tor7 | because then we could just drop the font (with all glyphs we can find) at the point we first spot them | 13:26.51 |
| Robin_Watts | but bugger good style :) | 13:26.54 |
| tor7 | and write out *all* glyphs, used or not | 13:27.10 |
| Robin_Watts | tor7: Right, if we're happy to send all the glyphs then it's easy :) | 13:27.18 |
| tor7 | Robin_Watts: one other option would be to write out webfonts | 13:27.56 |
| Robin_Watts | http://caniuse.com/svg-fonts | 13:27.59 |
| | So Firefox can't do svgfonts :( | 13:28.12 |
| tor7 | oh bugger :( | 13:28.28 |
| Robin_Watts | Nor can IE. | 13:28.34 |
| tor7 | so then, use/def or webfonts it is | 13:28.35 |
| Robin_Watts | use/def wins for me. | 13:28.52 |
| tor7 | yeah. def/use wins for keeping things simple and in one file | 13:29.16 |
| | svgfonts would be ideal if the support was there | 13:29.24 |
| Robin_Watts | tor7: def/use has the advantage of saving me having to go to 2 passes for now. | 13:29.43 |
| tor7 | hm, looks like inkscape can't use svgfonts either... | 13:30.29 |
| | https://bugs.launchpad.net/inkscape/+bug/170963 | 13:31.20 |
| Robin_Watts | tor7: http://ghostscript.com/~robin/out2.svg | 15:14.27 |
| | Looks to be working, except I've lost all my descenders :( | 15:14.48 |
| tor7 | Robin_Watts: yeah, it looks like it's clipping the glyphs | 15:15.02 |
| paulgardiner | Close though | 15:15.28 |
| Robin_Watts | It's automatically calculating the extent for each "symbol". | 15:15.55 |
| | (i.e. I don't give a width/height for each glyph as a I define it, svg figures it out for itself) | 15:16.15 |
| | BUT it seems to clip that to 0,0 on the left/bottom, helpfully. | 15:16.31 |
| tor7 | Robin_Watts: yeah, looking at the svg source I can't see anything odd | 15:16.40 |
| Robin_Watts | And I can't see a way to tell it not to. | 15:16.42 |
| tor7 | Robin_Watts: I need to leave for dinner, I'll be back in a while. | 15:17.04 |
| Robin_Watts | I could offset every glyph a bit, and then allow for that in the transform in the use call. | 15:17.14 |
| | tor7: OK. I may burble here for a bit. | 15:17.23 |
| | When I ask for the path, I could calculate the bbox from that, and then store the required offset per glyph. | 15:18.20 |
| | Currently I am storing a single bit per glyph in a font (have I sent this glyph yet?). | 15:18.49 |
| | If I had a font bbox, I could use that, but AIUI, you can't trust the font bboxes for most fonts. | 15:19.16 |
| | As an example: http://ghostscript.com/~robin/out3.svg | 15:54.04 |
| | oops. | 15:54.18 |
| paulgardiner | Robin_Watts: could you use the ascender and descender? I had yo use them in the pdf device for something... maybe not present for all fonts though. | 15:54.26 |
| Robin_Watts | Version where I shift the text box a bit: http://ghostscript.com/~robin/out3.svg | 15:54.36 |
| | For each glyph I find it's bbox, and shift the path so it's entirely positive, and shift back on use. | 15:55.01 |
| | BUT this reveals another problem. | 15:55.09 |
| | The first line should say "(C) 1985-2006", but the "-" disappears. | 15:55.52 |
| paulgardiner | I was just thinking with use of the ascender and descender values, you might be able to use the same bounds for the entire font | 15:56.07 |
| | </non-font-expert-comment> | 15:56.33 |
| kens2 | You cna't trust those (if available) any more than the BBox | 15:56.51 |
| Robin_Watts | paulgardiner: Yeah, and they aren't available from an fz_font :) | 15:57.24 |
| paulgardiner | Maybe it wasn't in the pdf device I used them then. Must have misremembered | 15:58.06 |
| mvrhel_laptop | good morning | 16:09.01 |
| Robin_Watts | mvrneh | 16:11.56 |
| | mvrhel_laptop: Morning. | 16:12.05 |
| | Sorry about that. | 16:12.10 |
| mvrhel_laptop | no worries. the name is difficult to spell | 16:12.25 |
| | and say | 16:12.36 |
| Robin_Watts | even so, that was a very poor effort :) | 16:12.42 |
| henrys | Robin_Watts: have you told paulgardiner about the cliff he is going to jump uhum - the MS Office project? | 16:16.10 |
| Robin_Watts | henrys: I haven't. I thought I'd let you communicate that. | 16:16.35 |
| mvrhel_laptop | I can't get AR to save this file that I want to edit to track down this bug | 16:16.40 |
| paulgardiner | I thought making me work on iOS was mean enough! :-) | 16:16.55 |
| mvrhel_laptop | Robin_Watts: you interested in looking at this for a second for me? | 16:16.59 |
| Robin_Watts | mvrhel_laptop: Sure. | 16:17.05 |
| henrys | paulgardiner: well we'll talk at the meeting tomorrow, lots of noises from customers for some way to print and view MS Office stuff⦠I thought looking at some open source stuff first might make sense, like Apache POI | 16:19.14 |
| mvrhel_laptop | Robin_Watts: just emailed it to you. I want to be able to save it in AR since I do some content removal with AR | 16:19.42 |
| Robin_Watts | ok. | 16:19.49 |
| mvrhel_laptop | AR will open it and display it just fine | 16:19.51 |
| paulgardiner | Actually I must be suffering from some kind of sickness because that sounds like fun. I should regain my sanity by tomorrow | 16:19.55 |
| mvrhel_laptop | with my knockout changes, cmyk rendering is different in clist vs nonclist | 16:20.17 |
| | which is what I want to track down | 16:20.29 |
| henrys | paulgardiner: give me some of whatever you're taking... | 16:20.43 |
| Robin_Watts | mvrhel_laptop: That's one of our standard test files, right? | 16:20.48 |
| mvrhel_laptop | yes | 16:20.53 |
| | Bug6901014_CityMap-evince-pdftopdf.pdf | 16:21.22 |
| paulgardiner | henrys: it's highly illegal! Anyway you can't talk: you run marathons. | 16:21.28 |
| Robin_Watts | paulgardiner: Have you decorators been leaving the white spirit out again? | 16:22.07 |
| paulgardiner | :-) | 16:22.13 |
| kens | Goodnight all | 16:22.45 |
| paulgardiner | Night kens | 16:22.54 |
| Robin_Watts | mvrhel_laptop: Interesting. I get the same problem here. | 16:23.43 |
| mvrhel_laptop | same as in you can not save? | 16:23.58 |
| Robin_Watts | Do you care about images or line art ? | 16:24.01 |
| mvrhel_laptop | or diff in clist? | 16:24.03 |
| Robin_Watts | Even after pdfcleaning it, I cannot save it from Acrobat. | 16:24.24 |
| mvrhel_laptop | Robin_Watts: so look in my bmpcmp first page | 16:24.38 |
| | you will see that the whole center map has a black plane | 16:24.55 |
| | that it should not have | 16:24.58 |
| Robin_Watts | OK, so I can remove images without ruining it. | 16:25.22 |
| mvrhel_laptop | so there is some large mask or trans group that is causing the issue | 16:25.28 |
| Robin_Watts | mvrhel_laptop: How about I remove bits from the file, and you tell me if the problem is still there? | 16:26.37 |
| | or... could you mail me a windows binary that shows the problem ? | 16:27.53 |
| mvrhel_laptop | Robin_Watts: I am sorry. I don't mean to make a bunch of work for you. | 16:31.10 |
| | let me send the binary | 16:31.26 |
| Robin_Watts | mvrhel_laptop: No worries. You're saving me from the insanity that is SVG. | 16:31.27 |
| mvrhel_laptop | hmm. It might be easier to send you a patch | 16:33.48 |
| Robin_Watts | mvrhel_laptop: Sure. | 16:33.57 |
| mvrhel_laptop | Robin_Watts: ok. sent you a patch | 16:39.46 |
| | sorry it took so long. I had to amend it with some changes and rebase | 16:39.56 |
| Robin_Watts | np. | 16:40.07 |
| | Does it only show up with pkmraw ? | 16:42.42 |
| mvrhel_laptop | no tiff32nc also | 16:42.52 |
| Robin_Watts | so it's cmyk specific? | 16:43.11 |
| mvrhel_laptop | yes | 16:43.15 |
| | and clist only | 16:43.21 |
| Robin_Watts | ok. I can reproduce it here. | 16:44.49 |
| mvrhel_laptop | oh good | 16:44.56 |
| Robin_Watts | It's R7 at fault. | 16:45.16 |
| | A deviceRGB Transparency group that overlays the whole image. | 16:45.53 |
| | s/image/map/ | 16:45.59 |
| | Using a pattern. | 16:46.10 |
| mvrhel_laptop | oh a pattern! | 16:46.15 |
| | that is likely the issue | 16:47.15 |
| henrys | Robin_Watts: Incidentally a global and a lock can be used for the openjpeg memory stuff, why was that solution dismissed? | 16:47.36 |
| mvrhel_laptop | if you can chop it down a bit for me that would be greatly appreciated | 16:47.38 |
| Robin_Watts | oh, and there is a softmask. | 16:52.48 |
| mvrhel_laptop | of course | 16:53.24 |
| Robin_Watts | I think it might be the softmask that's the problem. | 16:53.34 |
| | no, maybe not. | 16:54.23 |
| | the softmask alone is not the problem, but the softmask does contribute to the problem. | 16:54.45 |
| mvrhel_laptop | ok | 16:54.52 |
| Robin_Watts | OK, not the pattern at fault. | 17:00.54 |
| mvrhel_laptop | really | 17:01.23 |
| Robin_Watts | yeah, I removed the pattern from the file - same issue remains. | 17:01.41 |
| mvrhel_laptop | well that will make life easier | 17:04.00 |
| Robin_Watts | mvrhel_laptop: Cutdown file on its way. | 17:09.58 |
| mvrhel_laptop | Robin_Watts: thank you very much | 17:10.29 |
| Robin_Watts | no worries. I don't think I cut it down too much. | 17:10.48 |
| | I can possibly shrink it a bit more, but I risk making it hard to tell if it's working or not :) | 17:11.17 |
| mvrhel_laptop | Robin_Watts: perfect thanks | 17:16.15 |
| Robin_Watts | Interesting. | 17:16.25 |
| | The central group contains a stroke | 17:16.42 |
| | a semi-opaque stroke around the edge of the page. | 17:16.57 |
| | which is what produces the box. | 17:17.02 |
| | If you move the stroke off the page, the central region of the stroke changes colour. | 17:17.34 |
| | It's as if it's doing a stroke+fill. | 17:17.41 |
| mvrhel_laptop | right now I am comparing the much reduced raw images in clist vs non-clist case to see where things are different | 17:19.12 |
| Robin_Watts | And if I change it to be a triangle rather than a square, some bands look correct, others don't. | 17:20.07 |
| | I think the detection for "is there transparency in this band" may be screwy. | 17:20.24 |
| | If it will help, give me 10 mins and I'll get you a simpler file. | 17:20.42 |
| mvrhel_laptop | ok | 17:20.46 |
| | every bit helps | 17:20.51 |
| | oh I do see where things are going astray though | 17:22.07 |
| | I believe | 17:22.11 |
| | in the non-clist case, the backdrop is being color managed and in the clist case it is not | 17:23.28 |
| Robin_Watts | OK, smaller version on the way. | 17:29.07 |
| | Page contents = rectangle, then a triangle on top of it. | 17:29.27 |
| | Then this is overlaid by the group with an SMask. | 17:29.46 |
| | the smask is just a rectangle and the group contents should be a stroked triangle. | 17:30.15 |
| | sorry, the group contents should be 2 sides of the square stroked. | 17:30.44 |
| | The file should be entirely valid. | 17:30.51 |
| | and yet gs reports that the file did not complete the page properly. | 17:31.03 |
| | so this might point to an imbalance in gs's transparency handling or something. | 17:31.18 |
| mvrhel_laptop | Robin_Watts: ok thanks | 17:31.41 |
| | I do see an issue with the groups color profile missing during the clist reading which I think is the source of the color issue | 17:32.20 |
| Robin_Watts | tor7: 2 commits on robin/master for you then. (The SVG ones) | 17:41.37 |
| mvrhel_laptop | Robin_Watts: I was able to fix the issue | 18:18.45 |
| | thanks a bunch for cutting that down | 18:18.51 |
| Robin_Watts | fab. | 18:18.52 |
| | no worries. | 18:18.55 |
| mvrhel_laptop | that saved me a bunch of time | 18:19.00 |
| Robin_Watts | does gs still report the error ? | 18:19.02 |
| mvrhel_laptop | oh. let me try the other newer file | 18:19.14 |
| Robin_Watts | I have to pop out for a bit. | 18:21.12 |
| mvrhel_laptop | Robin_Watts: it works fine now | 18:21.33 |
| | and another cluster push to see what remains. | 18:32.15 |
| | in this work to fix the knockout stuff, I have managed to fix a couple other transparency issues | 18:32.34 |
| | that I stumbled upon during the review of bmpcmp | 18:32.50 |
| ray_laptop | ahh, good. I beat mvrhel_laptop to the cluster ;-) | 19:16.32 |
| mvrhel_laptop | ray_laptop: no. I am long done | 19:16.43 |
| | working on a new batch of issues | 19:17.01 |
| | from that run | 19:17.06 |
| ray_laptop | found yet another saved-pages bug that caused bunches of differences | 19:17.09 |
| | mvrhel_laptop: good. I was just kidding anyway. | 19:17.26 |
| | if I forget tomorrow, I want to see what anybody thinks about making the saved-pages a little more idiot proof. | 19:22.16 |
| | 1. accepting -saved-pages (adding a special check for this). It's not likely someone will want to set a string named "aved-pages" | 19:22.17 |
| | 2. If --saved-pages=begin or --saved-pages-test is placed before -sDEVICE= don't take immediate action, but wait until we do the init2. | 19:22.19 |
| | (Marcos tripped over this in setting up the weekly test of --saved-pages-test) | 19:22.20 |
| | time for lunch. bbiaw | 19:31.20 |
| mvrhel_laptop | sigh looks like I have some spot color issues | 19:34.41 |
| | actually overprint issues it appears | 20:43.51 |
| | what a pain | 20:43.53 |
| | and another soft mask issue that I stumbled upon | 21:12.32 |
| | taking a break. | 21:12.37 |
| ray_laptop | Oh, this is interesting. It seems that tests_private/comparefiles/Bug690714.pdf.ppmraw.72 has a difference with clist mode *WHERE THE CLIST MODE MATCHES ADOBE* and the page mode is missing a dashed line on page 3 (below "PATIENT STATEMENT") | 22:00.38 |
| | mvrhel_laptop: tests_private/comparefiles/Altona_Technical_v20_x4.pdf looks wrong on page 7 (the bottom rightmost corner). I also see a difference on the second from the left D between clist and page mode, but that (probably) isn't your issue. | 22:16.08 |
| | mvrhel_laptop: if you test it with your WIP and it's still wrong, let me know and I'll open a bug. The command line is: | 22:18.25 |
| | gswin32c -sDEVICE=ppmraw -o out.ppm -dFirstPage=7 -dLastPage=7 tests_private/comparefiles/Altona_Technical_v20_x4.pdf | 22:18.26 |
| | hmm.. why did that wrap after "compar" ??? | 22:19.02 |
| | mvrhel_laptop: if you add -dMaxBitmap=0 you'll see the page mode is slightly different | 22:21.39 |
| mvrhel_laptop | ray_laptop: I am so deep right now in getting this knockout stuff figured out, I may look at that issue later | 22:35.50 |
| | that file is one though that I have fixed several issues with though | 22:36.02 |
| | with what I am working on | 22:36.08 |
| | that file has knockout groups | 22:36.22 |
| | and lots of other various things going on | 22:36.30 |
| ray_laptop | mvrhel_laptop: another one that I see differences on is tests_private/comparefiles/Bug692720.pdf (clist vs. non-clist). Some of the yellow text goes away | 22:44.44 |
| mvrhel_laptop | ray_laptop: what change is causing these differences? | 22:45.32 |
| | or are you just looking at head | 22:45.38 |
| ray_laptop | mvrhel_laptop: Why clist vs. page mode make a difference, I don't understand | 22:45.39 |
| | mvrhel_laptop: I'm looking a differences with --saved-pages-test mode and on the "serious" diffs, I've determined that they are clist vs. page mode (so far) | 22:46.43 |
| mvrhel_laptop | ray_laptop: and they happen in head or with your change? | 22:47.02 |
| | I guess I am a bit confused | 22:47.20 |
| ray_laptop | I need a way to compare the --saved-pages-test mode with the .1 (clist mode) results | 22:47.23 |
| | mvrhel_laptop: the two I've mentioned happen in HEAD with clist vs. page mode | 22:47.52 |
| | but running --saved-pages-test FORCES clist mode, regardless if -dMaxBitmap=300m | 22:48.24 |
| mvrhel_laptop | i see | 22:48.29 |
| | ok. I can help out after I get this knockout stuff done. | 22:48.46 |
| | need to take kids to piano now.. | 22:48.56 |
| ray_laptop | so a LOT of the .0 pages differ with --saved-pages-test forced. | 22:49.05 |
| | mvrhel_laptop: I have to pick up my son from robotics class. bbiab | 22:49.23 |
| | Forward 1 day (to 2013/10/08)>>> | |
IRC Logs
