| | <<<Back 1 day (to 2012/05/28) | 2012/05/29 |
| fr500 | hi | 01:12.03 |
| ghostbot | hey | 01:12.03 |
| Robin_Watts | fr500: Did you have a question? | 09:14.28 |
| Halabund | Hi! | 11:16.12 |
| | Some of you guys may know the answer to this one: | 11:16.19 |
| | Is it technically possible to have interactive "spoilers" or "hints" in a PDF? I need something that is not normally displayed, but it's very easy to display it (preferably using mouse hover). | 11:16.56 |
| sebras | Halabund: you should look into PDF annotations. | 11:17.19 |
| Halabund | I'm not looking for a way to make a PDF like this now, I'd simply like to know if it is possible at all to have this. | 11:17.19 |
| Halabund | facepalms ... | 11:17.39 |
| sebras | ? | 11:17.53 |
| Halabund | sebras, you're right, that should work very well in practice | 11:18.02 |
| | thank you | 11:18.05 |
| Robin_Watts | Halabund: Except that won't work on devices that can't display annotations. | 11:18.55 |
| | or mouse overs (like touch devices). | 11:19.04 |
| | Google for UHS (Universal Hint System) | 11:19.19 |
| Halabund | Robin_Watts, that's true too. Ideally it would be something that's always displayed f the viewer doesn't support interactivity (like Adobe Reader), but it's only displayed on mouseover if it does. | 11:19.54 |
| sebras | Robin_Watts: is UHS based on PDF? | 11:20.05 |
| Robin_Watts | You could do something like that using PDF forms to hide/reveal answers. Or javascript to unscramble things. | 11:20.07 |
| | But UHS is available on so many platforms now that you might as well use it. | 11:20.23 |
| | sebras: No. | 11:20.30 |
| sebras | Robin_Watts: ok. hard to know from their webpage. | 11:20.48 |
| henrys | kens:on stackoverflow pipitas recommended pspcl6.exe for pdfwrite which is extremely screwy, do you want to tell him to use pcl6 since you regularly contribute? | 14:33.11 |
| kens | Hmm, do you have a title I can look for henrys ? | 14:33.46 |
| henrys | Converting PCL to PDF | 14:34.05 |
| kens | OK I'll find it and comment | 14:34.13 |
| | Got it | 14:34.54 |
| | comment added | 14:36.02 |
| henrys | I wonder if we should also try to sell to that other poster who is using PageTech, probably not worth it. | 14:36.30 |
| kens | At a guess, no, not worth it | 14:38.29 |
| Robin_Watts | tor8, henrys, paulgardiner: 20 mins to forms meeting? | 14:39.37 |
| paulgardiner | Ok | 14:39.54 |
| henrys | right | 14:40.02 |
| | looks like progress was good this week paulgardiner | 15:00.42 |
| paulgardiner | Yeah not bad. I was pleased to get another example file fully working. | 15:01.47 |
| Robin_Watts | Did you get the archive of test files off casper ? | 15:02.11 |
| henrys | that reminds me I was hoping alexcher would go through his files for acroform examples. | 15:03.07 |
| paulgardiner | Robin_Watts: I did, and I also have some example from another collection I have access to. I now have around 2500 files with some sort of form | 15:03.10 |
| Robin_Watts | Excellent. | 15:03.29 |
| henrys | paulgardiner:so maybe we have enough tests. | 15:03.33 |
| Robin_Watts | How hard would it be to grep them for different types of objects? | 15:03.57 |
| paulgardiner | henrys: possibly. Quantity wise we are good, but feature covering maybe not. | 15:04.04 |
| Robin_Watts | I would hope with 2500 files, that if we don't have an example that uses a feature, it's probably not commonly used :) | 15:04.39 |
| | I was just thinking, could we easily grep the files to see how many use checkboxes, how many use tickboxes, how many use javascript, etc. etc. | 15:05.20 |
| paulgardiner | I'm finding the vast majority are very boring, looking like they don't use javascript at all. Not surprising I guess. | 15:05.38 |
| Robin_Watts | To prioritise the features we (you!) get to implement. | 15:05.46 |
| | That surprises me. | 15:05.58 |
| | I'd have expected that all forms need some kind of javascript, if only for validation | 15:06.18 |
| paulgardiner | Yeah, grepping for javascript definitely. On the field type front, all the tyoes of field are used very commonly. | 15:06.46 |
| | There aren't that many types of field, so that's not a problem | 15:07.32 |
| Robin_Watts | Is grepping for the particular javascript interface used feasible? (To tell us whether SOAP etc is used) | 15:07.46 |
| paulgardiner | Robin_Watts: Yeah that too might well be useful. | 15:08.23 |
| | So far I've been just opening then in Acrobat Reader. Most show no sign of using javascript, and are clearly intended to be filled out and printed. | 15:09.09 |
| henrys | The fts files should go to some effort to test different features, though I haven't looked at forms specifically. | 15:09.14 |
| paulgardiner | Sorry fts? | 15:09.32 |
| henrys | at least that is why we pay for Quality Logic files - presumably they are designed to be good tests. | 15:09.44 |
| Robin_Watts | F***** test suite | 15:09.45 |
| | :) | 15:09.59 |
| paulgardiner | Robin_Watts: I hate t admit that was exactly my first guess | 15:10.12 |
| henrys | Functional Test Suite | 15:10.24 |
| paulgardiner | "Functional". Ah yes that's much better. :-) | 15:10.49 |
| Robin_Watts | The fts files are in tests_private | 15:11.17 |
| paulgardiner | So by fts are we talking about the files that Robin_Watts grepped through? | 15:11.22 |
| Robin_Watts | and so you've got the relavent ones in that archive. | 15:11.25 |
| paulgardiner | AH right. | 15:11.41 |
| Robin_Watts | fts is a small subset of tests_private | 15:11.56 |
| paulgardiner | Strangely, that included very few files with non-empty forms. | 15:12.07 |
| | 34 | 15:12.54 |
| henrys | paulgardiner:interesting we should complain. Actually the PostScript and PDF tests from Quality Logic have not ben that great - so I'm not surprised -- but we are "supposed" to pass them. | 15:13.27 |
| paulgardiner | Not sure why some files have a form with no fields | 15:13.36 |
| henrys | is tor8 about? | 15:14.11 |
| paulgardiner | I gesss files with forms may be a small percentage of pdfs | 15:14.13 |
| tor8 | henrys: I'm listening in. | 15:14.24 |
| henrys | you were going to look at one the form tasks also right? | 15:14.47 |
| | tor8 ^^^ | 15:14.51 |
| Robin_Watts | I suspect that the PDF fts was formed from the postscript FTS, and so coverage is biased towards the features of PDF that come from PS. | 15:15.10 |
| paulgardiner | I did find a few interesting files, some spread sheet like with calculated fields, some with submit buttons, some with one check box to enable other check boxes. | 15:15.16 |
| Robin_Watts | shall randomly capitalise things today. | 15:15.25 |
| tor8 | henrys: I'm writing a new desktop viewer | 15:16.03 |
| paulgardiner | tor8: Ah yes. We decided that was a prerequesite last week | 15:16.35 |
| henrys | tor8:I thought you were going to work on "fast partial update" also, or is that part of the viewer? | 15:17.02 |
| paulgardiner | One pain about fast partial update is that a lot of the work is in the individual apps... I think. | 15:17.50 |
| tor8 | henrys: we postponed that part for later | 15:17.50 |
| henrys | tor8:oh right. | 15:18.10 |
| tor8 | partial updates will need some sort of viewer integration as well | 15:18.17 |
| Robin_Watts | I thought that fast partial update was something we punted on, on the grounds that it wasn't required for a first version. | 15:18.24 |
| tor8 | so I think making a proper viewer with the integration for input is a prerequisite for that | 15:18.42 |
| henrys | paulgardiner:any new schedule thoughts with the work this week? | 15:18.44 |
| Robin_Watts | tor8: sounds plausible. | 15:18.53 |
| paulgardiner | henrys: Yeah:- | 15:18.58 |
| tor8 | paulgardiner: I've started on a Gtk+ based viewer, will see if I can refactor and use win32 with the same approach after that is running adequately. Gtk+ will work on windows as well, though, if you want to get involved earlier. | 15:19.32 |
| paulgardiner | If we released something now, the most noticable things missing would be multiline text, combed text, list boxes and combo boxes. I reckon I should look at them soon | 15:20.09 |
| | Also I'd be interested to look at the files with submit buttons, to see what's going on internally. | 15:20.32 |
| Robin_Watts | paulgardiner: Didn't you do some gtk stuff before on some phone or other? | 15:20.32 |
| tor8 | paulgardiner: I also meant to ask about integrating your patches, now that I've resurrected the old update the xref objects functions | 15:21.03 |
| paulgardiner | tor8: I was just about to ask you about that. Great. That's probably what I should do next. | 15:21.38 |
| henrys | paulgardiner:putting out some alpha code might get us some useful feedback. | 15:21.48 |
| | but not too alpha ;-) | 15:22.08 |
| paulgardiner | henrys: yes. and yes. | 15:22.19 |
| | :-) | 15:22.23 |
| | I think support for the other types of field are the main needs. | 15:22.44 |
| | multiline may be quite complicated. | 15:22.52 |
| henrys | multiline will presumably need some sort of text layout functionality? | 15:23.51 |
| paulgardiner | Yeah | 15:23.57 |
| Robin_Watts | It's no worse than "here is a rectangle, fill it with text" though, right? | 15:24.16 |
| paulgardiner | Yeah, it's not rocket science. | 15:24.31 |
| Robin_Watts | (I mean, it's not "here is a list of rectangles, and an exclusion zone and...") | 15:24.46 |
| | Even rocket science isn't rocket science these days. | 15:24.58 |
| paulgardiner | Exactly: thankfully it's not that | 15:25.04 |
| | That was a reply to the line above | 15:25.25 |
| | I mean two above Aggh! | 15:25.43 |
| | Fiddly is probably the word | 15:26.07 |
| henrys | I don't know getting into CJK and all that might be messy no? | 15:26.13 |
| Robin_Watts | henrys: Unless we have to support vertical motion, or left to right languages, we should be OK, I'd hope. | 15:26.47 |
| henrys | do you have a multiline example somewhere we could play with? | 15:26.48 |
| Robin_Watts | right to left, even. | 15:27.03 |
| paulgardiner | henrys: yeah plenty of examples now | 15:27.10 |
| | There's two modes, resizable to fit and not. | 15:27.30 |
| henrys | what's the filename? | 15:27.42 |
| | I was just curious to play around with it. | 15:28.03 |
| Robin_Watts | resizable to fit reduces the text size, right? That might be "interesting"... | 15:28.15 |
| paulgardiner | CATX2374 has a resizing multiline | 15:28.22 |
| tor8 | Robin_Watts: or languages with funky line breaking rules that don't use spaces | 15:28.22 |
| | Robin_Watts: or languages that need fancy glyph reordering | 15:28.41 |
| paulgardiner | I've yet to find a file that doesn't use /Helv | 15:28.49 |
| | :-) | 15:28.52 |
| Robin_Watts | has absolute confidence that paulgardiner will take all this in his stride :) | 15:29.09 |
| tor8 | but I doubt any of those will see use in PDF forms | 15:29.19 |
| paulgardiner | CATX5335 is non-resizing | 15:29.23 |
| | I will stride right over them, ignoring them completely. :-) | 15:29.53 |
| henrys | anyway it does look like progress is good, it would be nice if the status report had a list of tasks to be completed before alpha so we could have a better sense of schedule progress. Would that be okay? | 15:30.38 |
| paulgardiner | The pain about non-resizing is that both Chrome and AR create a scroll bar when you overflow the size of the box, seemingly just so you can type text that you wont be able to see in the finished form | 15:30.58 |
| Robin_Watts | paulgardiner: But which will be there when you submit it. | 15:31.31 |
| paulgardiner | Robin_Watts: oh yes of course. Good thinking | 15:31.54 |
| Robin_Watts | and it lets you paste stuff that's too big in, and cut it down. | 15:32.13 |
| paulgardiner | I was confused by it happening with a form that was clearly intended to by printed, but of course all cases must be supported. | 15:32.25 |
| ray_laptop | kens: I get a much easier to track error (segv) on your file when I run with -Z@ -- then it dereferences a pointer that has value 0xf1f1f1f1f1 | 15:33.20 |
| paulgardiner | henrys: yes. I have a much better idea now what missing features would most show. Wasn't so clear yesterday. | 15:34.41 |
| ray_laptop | kens: that's during the param_list_release. | 15:34.51 |
| paulgardiner | There are some tidying tasks too. At the moment I think it may be possible for fz exceptions to be thrown from v8 call backs. I don't think v8 would like that. | 15:35.38 |
| kens | ray_laptop : that didn't work for me, but OK, whatever you find works :) | 15:36.03 |
| paulgardiner | I dealt witht the other direction of bad interaction earlier | 15:36.08 |
| kens | ray_laptop : since its memory layout dependent, changing even small things can make the problem move. | 15:36.31 |
| | But even though the pointer is no longer circular, I think its the same basic problem. We have put a 'list' in the plist, and then freed the 'list' | 15:37.02 |
| henrys | sorry got a phone call. | 15:37.32 |
| | I'm off now. | 15:37.42 |
| paulgardiner | henrys: cyl | 15:37.51 |
| henrys | are we good for this week? | 15:37.58 |
| | no I meant I'm off the phone now. | 15:38.11 |
| paulgardiner | henrys: I think so. ta | 15:38.11 |
| Robin_Watts | has nothing to add. | 15:38.14 |
| henrys | tor8? | 15:38.22 |
| tor8 | I'm good | 15:39.18 |
| henrys | tor8, Robin_Watts:see you in 20 minutes for the next round. | 15:39.22 |
| Robin_Watts | tea! | 15:39.30 |
| henrys | coffee | 15:39.41 |
| paulgardiner | tor8: I don't think I have used gtk actually, but sure I could get involved if you could do with the help.. | 15:40.45 |
| mvrhel_laptop | good morning | 15:49.44 |
| kens | Morning Michael | 15:50.12 |
| henrys | mvrhel_laptop:welcome back - your buddy has been looking for you. | 15:50.19 |
| mvrhel_laptop | uhoh | 15:50.26 |
| Robin_Watts | I don't think henrys was referring to me, but I need to talk to mvrhel_laptop as well. | 15:52.15 |
| mvrhel_laptop | I am guessing he means cust 130 | 15:52.26 |
| | I think that issue is closed | 15:52.31 |
| henrys | no I was thinknig of advadhut. | 15:52.36 |
| mvrhel_laptop | we can be buddies too though Robin_Watts | 15:52.42 |
| Robin_Watts | gee thanks! :) | 15:52.55 |
| mvrhel_laptop | :) | 15:53.04 |
| henrys | I guess avadhut made it through the HP layoffs... | 15:53.20 |
| mvrhel_laptop | apparently | 15:53.31 |
| | not sure what to tell him | 15:54.04 |
| | except to run it in the manner that we told him to | 15:54.18 |
| Robin_Watts | I updated the downscaler so that we can do 16bit downscaling too (so James Cloos' submitted psdcmyk16 and psdrgb16) devices should work. | 15:54.25 |
| | and in so doing, I ran into the problem that he reported whereby the psdrgb device wasn't working at all. | 15:55.27 |
| tor8 | paulgardiner: since gtk works on windows, it may spare us the need to make a separate win32 application | 15:56.00 |
| Robin_Watts | I fixed one issue that was obviously wrong (credit to James for pointing it out) where we had the args to a memcpy the wrong way around in the rgb case. | 15:56.02 |
| tor8 | but I fear the compilation hurdles | 15:56.08 |
| Robin_Watts | but I was still getting all black output. | 15:56.20 |
| mvrhel_laptop | Robin_Watts: ok. is your fix submitted? | 15:57.06 |
| Robin_Watts | The encode/decode color routines were returning 0 for colors (due to pushing R<<(13*8) etc) | 15:57.09 |
| | so I reversed the order of encode so that R G and B stay at the bottom 24 bits - and I thought in testing on friday that had it solved, so I committed everything. | 15:57.47 |
| | But it turns out when I retested on monday, that I must have had finger trouble. So I still get black. | 15:58.09 |
| mvrhel_laptop | Robin_Watts: so with the 16 bit case, are we using the 16 bit planar buffers? | 15:58.19 |
| | Robin_Watts: maybe the black output predated your changes? | 15:58.49 |
| | I did not (and I should have) done testing with psdrgb | 15:59.01 |
| Robin_Watts | Black output predated my changes, yes. | 15:59.04 |
| mvrhel_laptop | ok then I will take over that | 15:59.16 |
| Robin_Watts | James' psdcmyk16 and psdrgb16 devices tweak the device setup for psdrgb too, so that it works - except in the spot color case where it gives a corrupted file. | 15:59.22 |
| mvrhel_laptop | ok | 15:59.43 |
| Robin_Watts | So I've put an updated version of his patch (with the downscaler changes) onto that bug. | 15:59.44 |
| | so that's probably a good starting point. | 15:59.51 |
| | Yes, he's using 16bit planar buffers. | 16:00.06 |
| mvrhel_laptop | ok great | 16:00.10 |
| | I am glad that I kept the new color type at 16 bits then | 16:00.49 |
| henrys | for the meeting opener we are down to 2 customer bugs any hope of fixing those? | 16:01.02 |
| mvrhel_laptop | ray_laptop: and I talked about it at the time and I really wanted 16 bit | 16:01.06 |
| henrys | I think ray_laptop and mvrhel_laptop or tor8 (xps) | 16:01.23 |
| mvrhel_laptop | let me guess that they are on my list | 16:01.24 |
| | hmm I have 2 on my list | 16:01.45 |
| | 692870 which i am going to hand off to Robin_Watts soon | 16:02.02 |
| ray_laptop | henrys: once I finish the pdf14 optimization, then I can get back to changes to use the clist for the pdf14 compositor for 'other' devices (vector, display, ...) | 16:02.04 |
| Robin_Watts | marcosw_ kicked the antialiasing enhancement back to a bug again. | 16:02.14 |
| mvrhel_laptop | and I have not had a chance to look at 692042 yet | 16:02.20 |
| tor8 | henrys: the latest xps bug wasn't a bug | 16:02.49 |
| henrys | Robin_Watts, marcosw: do we really have to go 1600 what about 800? | 16:02.52 |
| marcosw_ | Robin_Watts: not yet, suggested it | 16:03.11 |
| mvrhel_laptop | I meant 693042 | 16:03.21 |
| Robin_Watts | henrys: That would give 2 bits of antialiasing rather than 4. That may be enough. | 16:03.26 |
| ray_laptop | henrys: 1600 should give the same as AlphaBits=4 | 16:03.27 |
| Robin_Watts | marcosw_: What git revision did you run the performance test on? | 16:03.49 |
| ray_laptop | but I agree with Robin_Watts that 2 bits should suffice | 16:03.55 |
| marcosw_ | henrys: I tried 800 and the results are not particularly good. I can suggest it to the customer, but they've been using -dTextAlphaBits=4 | 16:03.57 |
| Robin_Watts | I'd like to understand why they feel they need antialiasing. | 16:04.19 |
| ray_laptop | marcosw_: well, we can use '3' (1200 dpi) -- that gives 8 levels of gray | 16:04.22 |
| henrys | marcosw_:that's surprising. | 16:04.33 |
| ray_laptop | Robin_Watts: they sent us a really zoomed in area of text where you can see the 'stepping' along the edges of curved chars. | 16:04.59 |
| Robin_Watts | if it's that gradients don't look right, then we should maybe look at the gradient decomposition code - maybe it's not decomposing enough. | 16:05.06 |
| henrys | Robin_Watts:they sent pics | 16:05.07 |
| | what ray_laptop said. | 16:05.12 |
| mvrhel_laptop | looking at the timings that marcos sent, I am thinking I will need to get copy_alpha working sooner rather than later | 16:05.47 |
| marcosw_ | Robin_Watts: I ran the tests using fad17657f6f583dbdef5a634d0f11dd79e446ffe | 16:05.50 |
| henrys | kens:anything for the meeting how's gs memory hell treating you? | 16:05.53 |
| kens | henrys there's only this problem with param lists | 16:06.07 |
| | I think the right way to fix it is for the param list code to 'deep copy' dictionaries, just as it does for arrays | 16:06.26 |
| marcosw_ | I don't think it's a gradient issue, the portion of the output image they sent that started this was small text. | 16:06.32 |
| kens | But I would very much like Ray's opinion | 16:06.34 |
| Robin_Watts | marcosw_: OK, that should be new enough. | 16:06.35 |
| henrys | alexcher:anything for the meeting? | 16:07.16 |
| alexcher | henrys: mooscript project is slowly developing. I'm now able to display simple images in deveice color spaces. | 16:07.25 |
| ray_laptop | kens: I am coming around to agreeing that freeing the dict.list looks funky. Ordinarily it gets freed in the 'param_end_write_dict' | 16:07.26 |
| Robin_Watts | It's probably worth profiling the files; if the slowdown is in the downscaler, then further optimising the 4x case may be worthwhile. | 16:07.40 |
| kens | ray_laptop : yes, putting something in the list, and then freeing it, is bad. | 16:07.44 |
| | but.... | 16:07.47 |
| | THe list code deep copies other compostite objects if they are not persistent | 16:08.04 |
| ray_laptop | but we don't want to leak if we aren't using GC memory | 16:08.05 |
| kens | ray_laptop : I don't 'think' we will | 16:08.15 |
| | Its the same as copying strings or arrays of strings | 16:08.29 |
| | Which are already copied by the act of putting them in a list | 16:08.40 |
| | c_param_write | 16:08.51 |
| Robin_Watts | kens: Was there originally a reason why the code didn't deep copy dicts? | 16:09.01 |
| kens | Robin_Watts : I have no idea | 16:09.08 |
| henrys | chrisl:any news on freetype? | 16:09.10 |
| Robin_Watts | (i.e. if you change it to deep copy stuff, is it going to suddenly break other stuff?) | 16:09.22 |
| kens | Possibly nobody needed dictionary parameters until pdfwrite came along | 16:09.24 |
| | Robin_Watts : I don't believe it will break anything but, as Ray says, I will need to be careful about freeing on list destruction | 16:09.52 |
| | But there must be code for this to cope with string arrays and such | 16:10.09 |
| Robin_Watts | kens: Are such things DAGs, or is there potential for cyclicness ? | 16:10.14 |
| chrisl | henrys: I've got the "core" FAPI functions with no direct PS dependencies, and I'm now working on the build side of getting that core into the graphics lib - so progress, but a couple of dead ends held me up a bit. | 16:10.16 |
| marcosw_ | I put the bitmap output demonstrating the need for antialising from the customer on the internets: http://marcosw.no-ip.com:8080/artifex/comparison.jpg | 16:10.30 |
| Robin_Watts | (like PDF pagetrees have a parent pointer) | 16:10.31 |
| kens | Robin_Watts : THere should not be cyclic references | 16:10.34 |
| | At least at the moment.... | 16:10.58 |
| Robin_Watts | marcosw_: I really wish they hadn't sent a jpg :( | 16:11.10 |
| marcosw_ | I can convert it to tiff for you :-) | 16:11.24 |
| mvrhel_laptop | hehe | 16:11.33 |
| henrys | well the degradation should be reproducible with a lossless device. | 16:12.14 |
| mvrhel_laptop | henrys: so a big thing that I need to work on this week is for customer 532 to try and make it possible to get overprint simulation with an RGB device | 16:12.23 |
| marcosw_ | Robin_Watts: the PDF file that generated the bitmap is attached to the bug, so you can generate whatever bitmap output you like. | 16:13.22 |
| henrys | mvrhel_laptop, ray_laptop:well one of you should just tell advadhut you won't have time to work on whatever he is yammering about until next week - he did ask you both directly. | 16:13.25 |
| mvrhel_laptop | I elect ray_laptop | 16:13.40 |
| | he tends to be a bit more direct with customers than me | 16:14.01 |
| ray_laptop | mvrhel_laptop: thanks -- but fixing the PCL color problem is probably yours. | 16:14.02 |
| mvrhel_laptop | I agree | 16:14.11 |
| | but that is not what he is asking | 16:14.17 |
| ray_laptop | mvrhel_laptop: but I will be glad to tell him | 16:14.19 |
| mvrhel_laptop | he wants to know why his timing is different | 16:14.31 |
| ray_laptop | mvrhel_laptop: I thought he was saying "I can't run server mode, so I need FastColor" | 16:14.44 |
| | mvrhel_laptop: probably his timings are slower because he is running on an HP CPU | 16:15.10 |
| mvrhel_laptop | ok | 16:15.15 |
| | you are right | 16:15.18 |
| marcosw_ | I'll email the customer, asking them why they need antialiasing at 400 dpi and also if they can live with -dDownScaleFactor=2 or -dDownScaleFactor=3. | 16:15.19 |
| ray_laptop | marcosw_: sounds like a good plan | 16:15.44 |
| Robin_Watts | marcosw_: Well, their comparison shows why they need it. | 16:15.48 |
| mvrhel_laptop | I will take a quick look at the pcl issue | 16:15.54 |
| | to see if it is easy to fix | 16:15.58 |
| ray_laptop | Robin_Watts: except I don't know how zoomed in that is on the page. | 16:16.10 |
| mvrhel_laptop | the cust 532 issue is going to take a bit of time | 16:16.11 |
| alexcher | Do we know what function is slow at high dpi rendering? Perhaps, it can be improved. | 16:16.17 |
| Robin_Watts | but using DownScaleFactor=3 should save 40%+ of the time. | 16:16.18 |
| | alexcher: I suspect that it's just a matter of the fact that we're hitting 16 times as many pixels. | 16:16.50 |
| ray_laptop | mvrhel_laptop: they (532) are much more intent on my pdf14 optimization issue | 16:17.05 |
| mvrhel_laptop | ok | 16:17.11 |
| | well then I will spend today looking at advahut's issue | 16:17.38 |
| | dont send him an email | 16:17.44 |
| | I will reply to him after I take a look today | 16:17.53 |
| ray_laptop | mvrhel_laptop: that is all in and working -- I am running a regression test through 569 of our pages that have transparency comparing with to without the optimization | 16:18.33 |
| Robin_Watts | assorted PS speakers: I'm going to be getting a bug back from mvrhel any day now where we have a complaint that stroking transparent complicated paths is slow. He has a proposed fix which solves it by using a knockout group - but that hurts in 'simple path' cases. | 16:18.51 |
| henrys | mvrhel_laptop:okay it looks like fast color is pretty good based on marcosw_ findings. Strange advahut bumped into a problem | 16:18.56 |
| mvrhel_laptop | henrys: that is why I am hoping it is an easy fix | 16:19.21 |
| Robin_Watts | So I'm proposing to fix it by using the knockout group for complex paths, and the old method for simple ones. | 16:19.27 |
| mvrhel_laptop | I may need some pcl help from you henrys | 16:19.33 |
| ray_laptop | mvrhel_laptop: I'll know in a few hours if I have lots of work remaining (i.e., I missed something in the design), or whether I can give it to them to test | 16:19.35 |
| henrys | mvrhel_laptop:okay. | 16:19.43 |
| Robin_Watts | So I need some way, in postscript of assessing the complexity of a path. | 16:19.50 |
| ray_laptop | Robin_Watts: that sounds plausible | 16:19.54 |
| kens | Robin_Watts : deinfe 'complex' | 16:20.04 |
| henrys | Robin_Watts:subpath count? | 16:20.06 |
| ray_laptop | Robin_Watts: in PS ???? | 16:20.07 |
| Robin_Watts | I was proposing to add a new gs specific operator to return the number of elements in a path. | 16:20.16 |
| kens | You cna use pathforall to walk a path | 16:20.22 |
| marcosw_ | Does the banded/page-mode issue warrant a bug? (i.e. <http://marcosw.no-ip.com:8080/artifex/usefastcolor/tests_private__comparefiles__Bug692309.ps.pcxcmyk.300.0.page_1.png> vs <http://marcosw.no-ip.com:8080/artifex/usefastcolor/tests_private__comparefiles__Bug692309.ps.pcxcmyk.300.1.page_1.png>) | 16:20.38 |
| Robin_Watts | ray_laptop: Yes. To use knockout or to do it the old way is a decision that needs to be taken in the pdf interpreter. | 16:20.49 |
| chrisl | Robin_Watts: does the gs_path have a num segments entry? | 16:20.54 |
| ray_laptop | Robin_Watts: I think it would be better to add a 'C' operator to return what you need. | 16:20.55 |
| Robin_Watts | kens: I really don't want to do that for every path we stroke. | 16:21.10 |
| | ray_laptop: Right. That's exactly what I'm thinking. | 16:21.17 |
| kens | Robin_Watts : no, I wasn't sure what you were asking for though | 16:21.23 |
| ray_laptop | kens: walking the path from pathforall is likely to be slower and defeat the optimization | 16:21.30 |
| Robin_Watts | but before I do that, I'd like confirmation that there isn't an existing PS operator that does that. | 16:21.42 |
| mvrhel_laptop | marcosw_: that is odd. I would open a bug for me to look at for this | 16:21.50 |
| henrys | marcosw_: I would think so | 16:21.53 |
| kens | No there is no existing operator | 16:21.55 |
| henrys | you are missing data | 16:21.59 |
| marcosw_ | mvrhel_laptop and henrys: will do. | 16:22.06 |
| alexcher | Une can generate user path and get the length of the array. | 16:22.19 |
| | One can generate user path and get the length of the array. | 16:22.38 |
| ray_laptop | Robin_Watts: if there was an existing operator it would probably be in psi/zpath1.c and I don't see it | 16:23.11 |
| kens | Me neither and I'm looking, there certainly is no standard one | 16:23.29 |
| Robin_Watts | Ok, thanks all. I'll proceed as planned and add a .currentpathlength operator. Thanks. | 16:23.42 |
| henrys | anything else for this meeting? | 16:24.23 |
| Robin_Watts | Does anyone have the address of the person responsible for hintstreams and linearisation? | 16:24.25 |
| | I have a letter bomb here, but no idea where to send it... | 16:24.35 |
| chrisl | Robin_Watts: just send it to Adobe - we'll let them guess which particular abomination it relates to....... | 16:25.07 |
| ray_laptop | Robin_Watts: on the ISO committee ? You _could_ send it to Leonard Rosenthal -- he's active on the ISO committee | 16:25.10 |
| Robin_Watts | At best the spec is unclear. At worst it lies. | 16:25.27 |
| ray_laptop | Adobe will probably just say | 16:25.35 |
| kens | Robin_Watts : welcome to the PDF specification | 16:25.44 |
| ray_laptop | "Please address all issues to the ISO 32000 working group" | 16:25.50 |
| Robin_Watts | I spent all yesterday making files with acrobat and taking them to bits. | 16:26.04 |
| alexcher | Robin_Watts: We have a PS utility to parse hint stream and some comments in pdfopt. | 16:26.46 |
| henrys | Robin_Watts:have you looked at QPDF? | 16:27.25 |
| Robin_Watts | nope. | 16:27.38 |
| chrisl | qpdf looks like a pdftk type thing, but done in C++........ | 16:28.55 |
| henrys | so 10:30 shall we call it? | 16:29.54 |
| ray_laptop | alexcher what's the hint stream parser ? | 16:30.06 |
| alexcher | ray_laptop: it's a PS program that parses and prints the hint stream. | 16:30.45 |
| henrys | 10:30 mountain time that is. | 16:31.06 |
| ray_laptop | alexcher: I meant what is it's name (I assume it has 'usage' comments) | 16:31.09 |
| | henrys: just like the in person staff meetings... when the meeting is 'done' people hang around and talk about stuff that didn't get covered in the meeting :-) | 16:32.24 |
| alexcher | ray_laptop: lib/dumphint.ps | 16:33.10 |
| henrys | Robin_Watts:if you see something useful in qpdf and use it let me know so we can contribute something to his project. | 16:33.15 |
| ray_laptop | alexcher: thanks. | 16:33.19 |
| kens | ray_laptop : I've just proven to my satisfaction that when we release the parameter list, it frees the lists referring to the dictionaries contained within it. | 16:34.51 |
| | SO I can fix this 2 ways: | 16:34.58 |
| | 1) hacky; don't free the image dict list | 16:35.11 |
| | 2) Change the c_param_write code to make copies of non-persistent dictionaries when wiring a colleciton | 16:35.30 |
| marcosw_ | I have several meetings today (Tuesday is my busy day), so will be around but not paying attention (which is pretty much my normal state :-) ) | 16:35.43 |
| ray_laptop | kens: so the problem is when a dict param list contains another dict, right ? | 16:35.59 |
| kens | ray_laptop : not really | 16:36.07 |
| | When a parameter list contains a dictionary | 16:36.16 |
| Robin_Watts | kens: 2) sounds like it should fix your problem with minimal ill effects elsewhere. | 16:36.25 |
| kens | We don't 'deep copy' dictionaries when writing a collection to the lsit | 16:36.36 |
| | Robin_Watts : both will fix my problem, 2 is more work | 16:36.47 |
| | Biut I think its the 'right' solution | 16:36.55 |
| | To be honest, I'm amazed this hasn't come up before, it all looks terribly wrong | 16:37.29 |
| | But..... | 16:38.17 |
| | I don't 'own' this code )not sure who does) | 16:38.29 |
| | SO I don't want to make changes without asking | 16:38.38 |
| kens | assumes silence means nobody wants to own up to it | 16:41.18 |
| mvrhel_laptop | yes | 16:41.26 |
| henrys | yea nobody really owns it. | 16:41.39 |
| kens | So I guess its OK if I go and modiy (break horribly) the code then | 16:41.58 |
| henrys | It does seem odd to me we haven't tripped over this before. | 16:42.01 |
| kens | It will only affect pdfwrite/ps2write, I don't think any other device has dictionaries as parameters | 16:42.40 |
| | It looks like we've just been lucky in the past | 16:42.56 |
| | OK family is home, off for dinner, goodnight all | 16:45.27 |
| henrys | woops missed kens - for the logs I see a lot of dictionary parameters in gsdparam.c | 16:47.23 |
| mvrhel_laptop | henrys: so what is the best way for me to view the pcl outputs? should I run them through pdfwrite? | 16:48.14 |
| henrys | what is the output device and is this not reproducible in a regular raster device? | 16:48.43 |
| mvrhel_laptop | oh | 16:48.51 |
| | duh | 16:49.00 |
| | never mind not sure what I was thinking | 16:49.16 |
| | he is running out to ljet4 | 16:49.49 |
| | and to pcl5 | 16:49.52 |
| henrys | so pbmraw should reproduce the problem - or any 1 bit mono device. | 16:50.14 |
| | ljet4 is just compressed raster. | 16:50.35 |
| mvrhel_laptop | ok | 16:50.39 |
| | thanks | 16:51.18 |
| | henrys: ok. this issue should be easy to track down. it does happen with pbmraw | 17:05.13 |
| | ugh. I am surprised this issue did not show up eariler | 17:33.49 |
| | this is odd | 18:34.38 |
| | http://download-ghostscript-pdf.com/ | 18:34.40 |
| | an add that came up on google for me | 18:34.50 |
| | s/add/ad/ | 18:35.06 |
| | henrys: So, bug 693060 got me poking around to see who this is | 18:49.12 |
| | This http://www.ifax.com/products/hylafax/hylafax.html#PS_HylaFAX_Comparison is interesting | 18:49.23 |
| | they have 2 products | 18:49.30 |
| | and open source and an enterprise version | 18:49.40 |
| | I suspect that both use ghostscript | 18:49.53 |
| | the enterprise edition is $$$ | 18:50.00 |
| | are these guys customers? | 18:50.23 |
| | I will send this to miles and scott to look at | 18:52.12 |
| Robin_Watts | mvrhel_laptop: Interesting. | 18:55.28 |
| mvrhel_laptop | Robin_Watts: I don't see how they could keep these separate without being a customer | 18:55.52 |
| | this is interesting http://www.hylafax.org/content/Support#Commercial_HylaFAX_Support | 18:57.04 |
| | the support developers are one thing | 18:57.29 |
| | but those that offer a software package that is not GPL is suspicious | 18:57.52 |
| | henrys: I am going to mark 692926 as resolved | 19:01.45 |
| | with my last commit | 19:01.52 |
| Robin_Watts | mvrhel_laptop: It's possible they are driving gs "at arms length", so still within the letter of the GPL. | 19:04.01 |
| | but it's got to be worth checking out. | 19:04.10 |
| mvrhel_laptop | yes | 19:04.14 |
| | that can be a tightrope to do | 19:04.29 |
| henrys | mvrhel_laptop:definitely report to scott - we've had interactions with them several time and nobody reported them. | 19:04.34 |
| mvrhel_laptop | oh. they only run on Linux | 19:09.16 |
| | so they have gs through that | 19:09.53 |
| | I wonder if they want to be a support customer though | 19:11.23 |
| | ok hopefully avadhut is all set now. time to grab some lunch | 19:15.00 |
| ManDay | Why is that a djvu to pdf converted documented is about at least double the size? | 20:03.53 |
| | (the djvu is a poorly scanned white-black book) | 20:04.14 |
| Robin_Watts | ManDay: Impossible to say without seeing the file. | 20:05.19 |
| ManDay | that would be piracy | 20:05.35 |
| | :D | 20:05.37 |
| | Anyway, it's pretty much always like that | 20:05.46 |
| Robin_Watts | Right, but it's the structure of the file we'd need to analyse. | 20:06.32 |
| ManDay | http://depositfiles.com/files/djw2w5xbb | 20:06.35 |
| Robin_Watts | It's quite possible that the conversion has not been done in a good way. | 20:06.52 |
| ManDay | That might be, I used a website | 20:07.12 |
| sebras | Robin_Watts: isn't it simply because of the wavelet encoding? | 21:44.03 |
| Robin_Watts | sebras: I'm not familiar with djvu - I thought when I read something about it a while ago, all the technologies it used were in PDF (isn't jpeg2K wavelet?) | 23:17.28 |
| sebras | Robin_Watts: djvu uses IW44 for fore-/background images (and jbig2 for the mask), which I think is specific for djvu. | 23:21.28 |
| | but you're right in that j2k is wavelet based as well. d'oh. | 23:21.53 |
| | Forward 1 day (to 2012/05/30)>>> | |
IRC Logs
){kind=link}