| | <<<Back 1 day (to 2012/08/01) | 2012/08/02 |
| mvrhel | ray_laptop: what results did gs filter='.pdf.psdcmyk' give? | 03:44.34 |
| | Robin_Watts: I beat on 693240 a bit. There is something getting screwed up with the transfer function. It is not an ICC or a planar issue. I will fool with it more in the morning | 06:01.46 |
| chrisl_away | kens: Can you keep an eye on gs-devel for the next couple of days, and put off anyone with 9.06rc1 issues until I get back, please? | 07:03.25 |
| kens | chrisl_away : yes, sure. No problem. If its Till I may ask someone to look at the problem | 07:03.50 |
| | Just so its solved when you get back | 07:04.03 |
| | Just reading the 'pdfwite on Raspberry Pi' thread.... | 07:04.27 |
| chrisl_away | kens: well, if it's a "functional" problem, raising a bug and getting whoever to look at it would be best - I was more thinking about build issues, though. | 07:05.16 |
| kens | Build issues was wat I was tinking, someone else can always look into them. The sort of problem you solved for Till last night | 07:05.57 |
| chrisl_away | kens: okay, thanks. If it's Till, he'll post it here, anyway, so others will see it - I'm a bit more concerned about gs-devel, since not many of us frequent the list any more, but I do occasionally get responses about the RCs on there. | 07:30.10 |
| kens | NP chrisl_away I still get gs-devel (answered a question there last night in fact) | 07:39.15 |
| tkamppeter | chrisl_away, thanks for the quick fix yesterday, it works perfectly now. | 07:52.51 |
| chrisl_away | tkamppeter: np, I'm glad it was something easy/obvious! | 07:58.35 |
| ray_laptop | looks like changing from 14 to 32 colors _does_ hit performance, but Robin's patch does help. One last run pending, then I can post the results. | 08:41.19 |
| kens | I#'ll be interested to see it | 08:41.37 |
| ray_laptop | IMHO, we need to look at this and make sure that we want to (a) revert to 14 colorants or (b) keep the change to 32 and cherry pick Robin's patch or (c) change to 64 and cherry pick Robin's patch | 08:43.05 |
| kens | Wasn't there also a suggestion of a command-line option to set the number of components ? | 08:43.32 |
| ray_laptop | kens: going to bed now, but I'll pull together the summary tomorrow AM (hopefully early enough for you) | 08:43.46 |
| kens | Just curious ray_laptop don't get up early for me | 08:44.01 |
| ray_laptop | kens: if the array sizes are set to a MAX, then having a device param to set the num_components might resolve it, but I think (from a late night review of the regerssion runs) that Robin's patch may eliminate the need for a param (at least for performance reasons) | 08:45.45 |
| kens | Well that would be good enough I'm sure, thanks ray_laptop | 08:46.07 |
| ray_laptop | other than performance I am not aware of any reason to limit the number of components | 08:46.08 |
| kens | No, just perfornmance as far as I know | 08:46.21 |
| ray_laptop | kens: OK, thanks -- if you think of anything, post it here -- I'll review the logs in the AM | 08:46.45 |
| | g'nite | 08:46.50 |
| kens | bye ray_laptop | 08:46.53 |
| chrisl_away | Time for me to shut down mission control and head for the hills - hopefully this number of components things will be resolved by the time I get back! | 08:56.54 |
| kens | have fun chrisl_away | 08:57.05 |
| chrisl_away | Cheers! | 08:57.16 |
| sebras | Robin_Watts: oh.. that was surprising. | 09:09.11 |
| | Robin_Watts: right, now that I checked the webpage about the new algorithm I'm realize I've seen it before. | 09:11.49 |
| | Robin_Watts: though this is no PDF standard (yet), so are we to implement it? | 09:12.07 |
| | Robin_Watts: also it seems to be based on reverse engineering... | 09:12.21 |
| Robin_Watts | sebras: Well, Acrobat X produces files in that format. | 09:12.52 |
| sebras | Robin_Watts: I'll look at poppler and see if it handles it. | 09:13.41 |
| | Robin_Watts: seems like pdfref20 has not been released yet..? | 09:18.19 |
| Robin_Watts | sebras: No. | 09:18.27 |
| kens | There's a 2.0 in teh works ? O.o | 09:18.54 |
| sebras | kens: yes. | 09:19.01 |
| | kens | 09:19.04 |
| Robin_Watts | Actually, I found a webpage where it was for sale. | 09:19.05 |
| sebras | standardized by ISO. | 09:19.08 |
| | Robin_Watts: that might be the draft though... | 09:19.16 |
| kens | OMG< it'll be an awful spec then | 09:19.22 |
| Robin_Watts | http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?ics1=37&ics2=100&ics3=99&csnumber=53041 | 09:19.42 |
| | It says "Under development", yes. | 09:19.51 |
| sebras | kens: tor8 has already complained about the typography in the document that adobe prepared for ISO to start ISO 32000-1:2008 from... :) | 09:20.05 |
| kens | Its not so much the typography I object to as the convoluted and difficult to understand content.... | 09:20.27 |
| sebras | kens: yesh, I realized, but still! | 09:20.48 |
| kens | Typical that Adobe release a product against a draft spec.... | 09:20.58 |
| sebras | kens: I guess they still believe that they own the format... | 09:21.30 |
| kens | Well, possibly, but they did the same with JPEG2000 support, and tehy didn't own that :-( | 09:21.56 |
| | Which wouldn't matter so much, but something (I forget what) changed between teh draft and the standard which made Acrobat 'different' | 09:22.27 |
| sebras | oh, pdf2.0 is currently about 100 pages longer thatn pdf 1.7 over at ISO... yey. | 09:22.30 |
| kens | sebras that's probably just all the ISO boiler plate :-) | 09:22.47 |
| sebras | kens: so now adobe j2ks are still a special case? | 09:22.52 |
| kens | sebras as far as I'm aware, yes. IIRC its some deault value that changed, but its been a long time | 09:23.15 |
| sebras | ken:s :) well, I was thinking an added 100 pages between the pdf 1.7 and 2.0 where both are ISO style. | 09:23.21 |
| kens | default* | 09:23.23 |
| | sebras yes but I don't htink the 1.7 spec was fully 'ISO'ised | 09:23.57 |
| sebras | ok. I never bought the document from ISO so I can be convinced either way. | 09:24.31 |
| kens | I have several 'real' ISO dox :-( | 09:24.47 |
| | that is bought for real money.... | 09:24.58 |
| sebras | kens: let's hope the moneys weren't your own. | 09:25.27 |
| kens | Nope, expenses :-) | 09:25.37 |
| sebras | Robin_Watts: nope, poppler doesn't support V == 5, R == 6... | 09:30.10 |
| | have you guys seen the proposals for pdf 2.0? http://pdf.editme.com/pdfrefNewFeatures | 09:32.54 |
| | one of them were SWF-based navigators.... | 09:33.05 |
| Robin_Watts | oh god, please not flash. | 09:33.28 |
| sebras | it seems adobe thinks it's a dead technology elsewhere, but I wonder if the took that decision before or after settling the list of new features for pdf 2.0. | 09:34.07 |
| kens | I can see the 'Enforce' field causing confusion and anger | 09:35.54 |
| sebras | kens: ? | 09:36.12 |
| kens | It allows a document to set Viewer preferences, that subsequent UI controls are not allowed to change | 09:36.37 |
| sebras | kens: ah. but this is part of extensionlevel3, so this is not really new. | 09:37.29 |
| | tor8: morning tor8. | 09:37.36 |
| tor8 | morning all | 09:37.41 |
| Robin_Watts | Morning tor8. Are you returned from your travels? | 09:38.44 |
| tor8 | Robin_Watts: yes. back and ready to close bugs. | 09:38.58 |
| | how's the forms branch, we ought to merge that to master soon if we want an august release | 09:39.15 |
| Robin_Watts | tor8: See the logs from tuesdays meeting. | 09:40.44 |
| | I think the plan is now to release, then merge at leisure rather than to merge in a hurry and release. | 09:41.20 |
| sebras | Robin_Watts: http://forums.adobe.com/message/4095705 | 10:12.41 |
| tor8 | Robin_Watts: alright, seems sensible enough | 10:24.23 |
| | Robin_Watts: any outstanding bugs we want to squash before release? | 10:24.43 |
| | I didn't figure out the odd soft mask + tiling thing going wrong in muxps last week :( | 10:25.13 |
| sebras | Robin_Watts: I just got the word: http://code.google.com/p/sumatrapdf/source/detail?r=6520 | 11:28.48 |
| Robin_Watts | tor8: I've been gsing, so I've not looked either. | 11:31.31 |
| paulgardiner | tor8, Robin_Watts: what's a good key to use in the app for saving the file? 's' is already taken. | 13:26.39 |
| kens | w? | 13:26.52 |
| paulgardiner | Actually, 's' is already taken only in the debug build. | 13:27.13 |
| | kens: oh yeah. that would make sense. | 13:27.26 |
| tor8 | paulgardiner: 'S' perhaps? | 13:27.46 |
| | or as kens said, 'w' but w is also taken by shrink-wrap and width-fit | 13:28.12 |
| paulgardiner | tor8: also good. Doesn't look to be in use. | 13:28.17 |
| | Robin_Watts, tor8: I have a few commits on my forms branch that could do with looking over if you have time at some stage. | 14:11.37 |
| Robin_Watts | looks. | 14:11.56 |
| paulgardiner | Oh. Not cluster tested yet. | 14:13.46 |
| Robin_Watts | paulgardiner: The "dirty" one. | 14:14.53 |
| | I wonder whether a flags word would be a good idea. | 14:15.08 |
| paulgardiner | What to role dirty and calculating into one? | 14:16.00 |
| Robin_Watts | I hadn't got as far as having an example :) | 14:16.56 |
| paulgardiner | :-) | 14:17.12 |
| Robin_Watts | We should possibly set the dirty flag if we repair a pdf file. | 14:17.20 |
| paulgardiner | Sounds sensible. Where can I pick that up? | 14:18.00 |
| Robin_Watts | pddfapp_save; should we use PATH_MAX rather than 256 ? | 14:18.24 |
| | Otherwise all looks great. | 14:18.41 |
| paulgardiner | Thanks. I'd go for leaving the flags word for now, but addressing the others. | 14:19.24 |
| Robin_Watts | pdf_xref.c. Look for "repaired = 1" | 14:19.50 |
| | you're probably right. | 14:20.04 |
| paulgardiner | Fixed those and a build problem. Now just waiting on a cluster test. | 14:52.32 |
| | ... which failed, so just fixing another build problem... | 14:58.48 |
| Robin_Watts | paulgardiner: Julie has fallen over and ripped her achilles tendon. All casted up. 10 weeks off work. I'm going to pop over and see her shortly. | 14:59.38 |
| paulgardiner | Oh no. Wish her well from me. | 15:00.13 |
| Robin_Watts | will do. | 15:00.18 |
| henrys` | alexcher:can you get the 2.0 spec and be prepared to talk about any new language features at the next meeting? Very curious what prompted the major version change. | 15:00.30 |
| Robin_Watts | henrys: I'd be very surprised if there were *language* changes (i.e. the pdf operators). | 15:01.12 |
| | Adobe stated years ago (v1.5 or something) in the spec that there would be no new operators. All new functionality would be added by using dictionary entries etc. | 15:02.07 |
| henrys` | I consider that a language change. | 15:04.05 |
| henrys | any ideas what is behind the major version number change? | 15:06.20 |
| Robin_Watts | Well, it's a change in possible functionality, but it means that we stand a reasonable chance that new files will be backwardly compatible (in the way that transparency was introduced). | 15:06.56 |
| | Of course compressed streams etc broke that, but... | 15:07.04 |
| | henrys: Well, it's v2 of the ISO spec, so they probably couldn't easily do v1.8 of pdf. | 15:07.31 |
| | Are we members of the ISO committee ? Should we be? | 15:08.03 |
| henrys | no but I have a connection, I'll shoot him some mail. | 15:08.31 |
| halfie_ | mupdf developers, how do I get file name of the pdf file in "pdf_needs_password" function? Can I get filename from pdf_document object? | 15:09.04 |
| henrys | there was discussion of ray_laptop joining but we decided against it. | 15:09.12 |
| Robin_Watts | halfie_: Why do you need it? | 15:09.26 |
| halfie_ | Robin_Watts, I am hacking mupdf to output crypt information. I am trying to write a PDF password brute force? I can save filename in a global variable. | 15:10.22 |
| | s/force/forcer | 15:10.31 |
| Robin_Watts | Currently the filename is not stored in the pdf_document object. | 15:11.57 |
| kens | henrys I scanned th draft spec and the proposals for consideration, most of what's there is new annotations. Eg more 3D things, more flash/video content. Some extra geo information for attachment to things like images. The big changes are in the 'navigation' area and GS doesn't need to worry about that. | 15:12.19 |
| halfie_ | Robin_Watts, I can hack pdfapp_open to save filename in a global variable. My attempts at writing a pdf parser for getting crypt information have failed :( | 15:12.37 |
| Robin_Watts | OK, then I think that's what you'll need to do. | 15:12.56 |
| halfie_ | Robin_Watts, will it be easy to rip extra libraries and code from mupdf (like jpeg, zlib and cbz etc)? | 15:14.18 |
| henrys | kens:well I am looking at Extension level 5 - it has trans changes. | 15:14.19 |
| kens | Hmm, didn't see that one | 15:14.29 |
| Robin_Watts | henrys: It adds 2 new blend modes, right? | 15:14.40 |
| henrys | fairly minor change to Blend Mode | 15:15.03 |
| Robin_Watts | ColorDodge and ColorBurn or something? | 15:15.04 |
| henrys | Robin_Watts:right. | 15:15.10 |
| | so I'll make a bug out of that and assign it to mvrhel | 15:15.38 |
| | and extension level 3 seems to have lots of stuff relevant to sue. | 15:19.40 |
| | s/sue/us | 15:19.44 |
| alexcher | henrys`: Yes, I'll do this. | 15:19.50 |
| Robin_Watts | I'm confused. Where in our mess of makefiles is gp_dosfs.c included ? | 15:20.00 |
| paulgardiner | Robin_Watts: those commits are ready for another look. No hurry of course. | 15:20.10 |
| henrys | thank you alexcher | 15:20.18 |
| Robin_Watts | henrys: The 2.0 spec isn't finalised yet, but it's free for members of the committee. Can you get a copy from your friend ? | 15:20.58 |
| henrys | alexcher:the way wikipedia describes it, 2.0 accepts extension level 3 and 5 so I guess you could just look at those documents until I contact somebody on the committee. | 15:23.43 |
| alexcher | OK | 15:24.02 |
| Robin_Watts | I thought I saw a reference to extension level 8 too. | 15:25.06 |
| henrys | yes this wiki page might be dated - it says 8 isn't published as of 5/11 | 15:26.52 |
| | we've done 1.3 256 AES encryption. | 15:27.39 |
| Robin_Watts | 8 describes the new security handler, AIUI. and that isn't available on the net. | 15:27.45 |
| henrys | not 1.3 but 1.7 extension 3 ... | 15:28.33 |
| | alexcher please create an enhancement for mvrhel about the new blend business. | 15:30.48 |
| alexcher | OK | 15:31.14 |
| henrys | http://esec-lab.sogeti.com/post/The-undocumented-password-validation-algorithm-of-Adobe-Reader-X | 15:34.23 |
| | Robin_Watts:I don't want to ask him for the spec but I will ask him if there are any surprises beyond the extension levels that we should be aware of. | 15:36.57 |
| halfie_ | are oe and ue only used by encrypted documents using revision 5? | 15:44.44 |
| henrys | kens:did we start the pdf output compare? I did send a message to the customer shooting down pursuing the idea but told them we would do this comparison and look for systemic problems. | 15:48.44 |
| kens | henrys I don't know, I thought Marcos was doing that. | 15:49.03 |
| | I sent him some suggested parameters | 15:49.28 |
| henrys | okay I saw that. | 15:49.45 |
| kens | Hmm I believe there's (yet another) bug in Acrobat's preflight. Its insisting that the BleedBox shuold be less than the MediaBox for PDF/X-3. The draft spec doesn't mandate that, I wonder if the final one does.... | 16:01.46 |
| | Anyone know who bob@rjofko.com is ? | 16:06.24 |
| | Looks like a free user.... | 16:06.43 |
| halfie_ | Can someone point me towards sample Revision 5 encrypted files? | 16:08.43 |
| henrys | is support at artifex dot com advertised to all at the mac app store? | 16:12.26 |
| kens | 'Its not our problem, go bother these people' | 16:13.01 |
| henrys | I can't believe badmitton and table tennis overlap which should I watch? | 16:15.35 |
| | hopefully marcosw will give him the customer speech and send him to bugzilla. | 16:16.10 |
| kens | OK I have to go, goodnight all | 16:20.17 |
| henrys | bye kens | 16:20.24 |
| Robin_Watts | Morning ray_laptop | 17:06.07 |
| | I have a patch that does -dMaxSpots for psdcmyk and tiffsep/tiffsep1 | 17:06.20 |
| ray_laptop | Robin_Watts: I assume that the arrays based on GS_CLIENT_COLOR_MAX_COMPONENTS or MAX_COMPONENTS_IN_DEVN are not affected -- just the color_info.max_components and num_components ? | 17:15.03 |
| Robin_Watts | ray_laptop: Absolutely. | 17:15.13 |
| | All arrays etc are set to GS_CLIENT_COLOR_MAX_COMPONENTS as they are now. | 17:15.41 |
| | MaxSpots is initialised to GS_SOFT_MAX_SPOTS (which is GS_CLIENT_COLOR_MAX_COMPONENTS-4 by default, but can be predefined) | 17:16.20 |
| | and -dMaxSpots overrides that. | 17:16.39 |
| | So, we can choose to release builds that are 'fast' (and have people use the flag to enable more components), or we can release builds that are 'slow' (and have people use the flag to get the speed back) | 17:17.25 |
| | ray_laptop: How did the timings results work out in the end? | 17:17.59 |
| ray_laptop | Robin_Watts: the timings I got were somewhat screwy, but it looks like the 'unpatched' version for psdcmyk goes from 11266 to 13281 then 14167 seconds (14, 32, 64, resp.) | 17:19.29 |
| | but then I didn't do the same timing for the patched version | 17:19.57 |
| | in percentages 18% from 14->32 then another 7% from 32 to 64 | 17:21.14 |
| | I'm going to repeat the 'total' psdcmyk for the patched version | 17:21.41 |
| Robin_Watts | ok. | 17:21.49 |
| ray_laptop | oops. wrong number. 64 was 19096 | 17:23.01 |
| Robin_Watts | Ah, that's more in keeping. | 17:23.22 |
| ray_laptop | so that makes 32->64 percentage be 43% | 17:23.42 |
| | Robin_Watts: the patched version from 32 to 64 for pdf.psdcmyk looks almost the same (two runs of 64 were over and under 32) | 17:26.33 |
| Robin_Watts | So the patch basically gets us back the 64->32 cost? | 17:27.03 |
| | That's more than I'd hoped for. | 17:27.13 |
| ray_laptop | Robin_Watts: since the results were a bit screwy, I'm retesting the filter=psdcmyk (both ps and pdf) with the patch | 17:28.35 |
| | Robin_Watts: starting 14 now | 17:28.45 |
| | Robin_Watts: I don't like making decisions on funky info, so might as well burn some cluster watts | 17:29.27 |
| | but I'm pretty sure that without the patch, changing to 32 (or 64) is NOT something we want to do. | 17:31.24 |
| Robin_Watts | ray_laptop: I suspect my preferred approach would be to change to 64, add the patch, and add the -dMaxSpots patch too. | 17:32.44 |
| | That way we ship builds that are maximally powerful, that don't take *too* much more time, and that can be accelerated to the old speeds by users using -dMaxSpots appropriately. | 17:33.29 |
| ray_laptop | Robin_Watts: I'm leaning that way. So the theory is that with -dMaxSpots=14 the timing with PS files will be no worse than GS_CLIENT_COLOR_MAX_COMPONENTS 14 | 17:34.25 |
| Robin_Watts | yes. | 17:34.33 |
| | http://git.ghostscript.com/?p=user/robin/ghostpdl.git/.git;a=commitdiff;h=402028ca735ffa051a78202f28d1dbb89ac69d76 | 17:34.48 |
| ray_laptop | Robin_Watts: but we don't really have a way to test that on the cluster, right ? (since we can't add arbitrary command line options) | 17:35.14 |
| Robin_Watts | ray_laptop: We can hack the cluster code :) | 17:35.28 |
| | I can make the cluster code add -dMaxSpots=14 to every tiffsep invocation. | 17:37.38 |
| | psdcmyk even. | 17:37.55 |
| | ray_laptop: OR... we can push with GS_SOFT_MAX_SPOTS set to 14 which will have the same effect. | 17:38.22 |
| | let me try a run now. | 17:39.21 |
| | You've been using filter=psdcmyk? | 17:40.02 |
| ray_laptop | Robin_Watts: yes | 17:40.52 |
| | specifically: gs filter=psdcmyk | 17:41.09 |
| Robin_Watts | D'oh, yes. Let me abort. | 17:41.31 |
| ray_laptop | Robin_Watts: and you have your plane compression patch in as well, right ? | 17:41.45 |
| Robin_Watts | yes. | 17:41.54 |
| ray_laptop | Robin_Watts: I'm running gs filter=psdcmyk with GS_CLIENT_COLOR_MAX_COMPONENTS 14 | 17:42.37 |
| | so your timing with 64 should be conclusive | 17:42.57 |
| tkamppeter | I see that GS 9.06 has an icclib directory in its source code. Is icclib actually used by GS? And by which parts? | 17:43.25 |
| Robin_Watts | I'm running: gs filter=psdcmyk with GS_CLIENT_COLOR_MAX_COMPONENTS 64, GS_SOFT_MAX_SPOTS 10 and the plane compression patch in. | 17:43.44 |
| tkamppeter | I do not find anything about icclib in config.log. | 17:43.44 |
| ray_laptop | Robin_Watts: with GS_CLIENT_COLOR_MAX_COMPONENTS 14 I got 3:09:40 (and NO timeouts!) | 17:43.52 |
| tkamppeter | If icclib is needed, how can I use an external icclib? | 17:44.09 |
| ray_laptop | tkamppeter: it looks like we don't use icclib anymore -- just lcms2 | 17:46.01 |
| | we can verify that with mvrhel | 17:48.00 |
| | maybe we should rm it from our tree and makefiles and make sure nothing breaks | 17:49.12 |
| Robin_Watts | ray_laptop: 3:05:48 | 17:50.44 |
| ray_laptop | Robin_Watts: sounds good. I'm going to go ahead with 32 and 64 with your compression patch (but no MaxSpots patch) | 17:52.05 |
| Robin_Watts | ray_laptop: Go for it. I'm busy with Windows 8 at the moment :( | 17:53.18 |
| ray_laptop | Robin_Watts: have fun ;-) | 17:53.35 |
| | Robin_Watts: basic Windows 8, or a "Metro app" ? | 17:54.00 |
| Robin_Watts | Metro. | 17:54.08 |
| ray_laptop | yuck | 17:54.14 |
| Robin_Watts | Windows 8 in 'desktop' mode is just Win32/Win64, no problems. | 17:54.27 |
| | It's trying to get something to compile under Metro that's the pain. | 17:54.41 |
| tkamppeter | ray_laptop, I have checked, nothing #includes the .h files of icclib, so can you fix the bug by removing icclib and all build system parts regarding icclib for the GS 9.06 final? Thanks. | 17:55.18 |
| ray_laptop | Robin_Watts: did you update the doc/Devices.htm with MaxSpots ? | 17:55.20 |
| Robin_Watts | Not yet. | 17:55.48 |
| ray_laptop | tkamppeter: we'll consider that, but no promises on removing it | 17:55.49 |
| Robin_Watts | Just what you see in the above patch. | 17:56.05 |
| ray_laptop | Robin_Watts: if you wait, I'll give you performance numbers (for filter=ps.psdcmyk) and you can mention "WHY" to use MaxSpots | 17:56.59 |
| Robin_Watts | will do. | 17:57.50 |
| mvrhel | I am here now | 17:57.50 |
| | ray_laptop: | 17:57.54 |
| ray_laptop | hi, mvrhel | 17:57.57 |
| mvrhel | kids had their last day of swim lessons had to go see what they had learned | 17:58.17 |
| Robin_Watts | Do we use icclib for anything now ? | 17:58.20 |
| ray_laptop | mvrhel: it looks like we no longer use icclib | 17:58.23 |
| mvrhel | no | 17:58.24 |
| | icclib should go away | 17:58.31 |
| ray_laptop | mvrhel: but we still have it in our makefiles and the tree is still there. oops | 17:58.45 |
| mvrhel | well it should go away | 17:59.08 |
| ray_laptop | I guess we can leave it for chrisl, or one of us can rip it out | 17:59.45 |
| | then chrisl can decide whether or not to cherry pick it | 18:00.01 |
| | Robin_Watts: GS_CLIENT_COLOR_MAX_COMPONENTS 32 with your patch is 3:46:20 | 18:02.48 |
| Robin_Watts | So 40 minutes cost. | 18:03.36 |
| | 22%. | 18:04.04 |
| mvrhel | on PDF? | 18:04.11 |
| Robin_Watts | The problem is that the cluster varies a fair bit anyway. | 18:04.13 |
| | No, on PDF+PS. (gs filter=psdcmyk) | 18:04.25 |
| | I think ray did tests last night that showed there was no measurable difference for pdf files. | 18:04.55 |
| | mvrhel: I have a patch that implements -dMaxSpots. (see the link earlier) | 18:05.21 |
| | running with MAX_COMPONENTS at 64 and the default number of maxspots at 10 (so giving 14 components overall) took 3:04:xx - pretty much identical to the MAX_COMPONENTS = 14 time. | 18:06.25 |
| mvrhel | Robin_Watts: ok that is good about pdf | 18:07.14 |
| Robin_Watts | So, (as I said to ray earlier), I think I'm in favor of shipping with MAX_COMPONENTS set to 64, GS_SOFT_MAX_SPOTS set to 60 (the default number for -dMaxSpots). | 18:07.32 |
| | That way people get the most powerful gs possible, but it might be a bit slower. And they can get the speed back by setting -dMaxSpots at runtime. | 18:08.16 |
| | and it's only slower for PS, of course. | 18:08.31 |
| mvrhel | I dont see the need to go to GS_SOFT_MAX_SPOTS of 60 though | 18:08.50 |
| | if that is slowing things down 99.9% of the files would need something much less | 18:09.39 |
| ray_laptop | Robin_Watts: I'm going to verify the performance hit for ps.psdcmyk next | 18:11.55 |
| Robin_Watts | mvrhel: I'd rather people needed to tweak gs for performance, than needed to tweak gs for correctness. | 18:12.11 |
| | but clearly mine is just one opinion. | 18:12.25 |
| mvrhel | I would not say that the output is going to be incorrect | 18:12.55 |
| Robin_Watts | Missing spots is incorrect, IMHO. | 18:13.14 |
| mvrhel | they will not be missing | 18:13.20 |
| | it would do the alternate tint transform and draw somthing | 18:13.34 |
| | in the composite | 18:13.40 |
| Robin_Watts | Right. | 18:13.42 |
| mvrhel | overprint simulation might fail to be correctly drawn though | 18:14.01 |
| Robin_Watts | That's still not ideal though. | 18:14.03 |
| mvrhel | ok I can push the same argument beyond 64 | 18:14.19 |
| Robin_Watts | I mean, we COULD ship with GS_SOFT_MAX_SPOTS set to any value we like. | 18:14.28 |
| | mvrhel: Right, but 64 is the maximum we can do :) | 18:14.38 |
| mvrhel | personally, I vote for speed but that is my 2 cents | 18:15.32 |
| | most customers will want speed | 18:15.39 |
| ray_laptop | GS_CLIENT_COLOR_MAX_COMPONENTS 64 is 5:31:11 (even with the compression patch) | 18:15.55 |
| mvrhel | but maybe since this is just the psdcmyk, tiffsep devices the question is not the critcal | 18:16.13 |
| | s/the/that/ | 18:16.27 |
| Robin_Watts | With the -dMaxSpots, we can fairly safely pick any value we want. | 18:16.58 |
| | The main thing is that customers like Gemma don't need to recompile to change the limit. | 18:17.13 |
| mvrhel | right | 18:17.19 |
| | oh I think your change is great | 18:17.30 |
| | I just don't think we want a large default value | 18:17.41 |
| | there is a warning displayed when we reach the limit in the number of colorants | 18:18.05 |
| | or there used to be. not sure if it still works after all these changes | 18:18.23 |
| Robin_Watts | Ah, well, if that's the case, we could make that say "rerun with -dMaxSpots=... to see all the spot colors" | 18:18.58 |
| mvrhel | yes | 18:19.05 |
| Robin_Watts | That would be nice. | 18:19.12 |
| ray_laptop | mvrhel: since -dMaxSpots ONLY applies to PS input files (which are not used by our customers, AFAIK), setting at a low number seems OK. | 18:24.10 |
| mvrhel | that is my thought | 18:24.28 |
| Robin_Watts | We don't have any PS customers? | 18:25.19 |
| ray_laptop | since up till now we had GS_CLIENT_COLOR_MAX_COMPONENTS 14 unless customers did their own build (or cajoled us into it), we could even make the default MaxSpots be 10 | 18:25.41 |
| mvrhel | yes | 18:25.53 |
| Robin_Watts | ray_laptop: That seems reasonable. | 18:26.00 |
| ray_laptop | Robin_Watts: we have PS customers, but not doing tiffsep (AFAIK) | 18:26.01 |
| Robin_Watts | Ah, I see! | 18:26.09 |
| ray_laptop | and no customers using psdccmyk | 18:26.19 |
| | that I know of | 18:26.27 |
| Robin_Watts | I think either we push it to 60, or leave it at 10. Either case has good arguments for it. | 18:26.42 |
| | My personal inclination would be 60, but it's not a strong preference, and I'm happy to be outvoted. | 18:27.05 |
| ray_laptop | Robin_Watts: I''m running ps.psdcmyk now | 18:27.07 |
| | ps.psdccmyk GS_CLIENT_COLOR_MAX_COMPONENTS 14 is 17:05 | 18:28.27 |
| | these filtered tests are REALLY quick to run | 18:29.06 |
| Robin_Watts | yeah. Almost as fast as mupdf ones :) | 18:29.28 |
| ray_laptop | Robin_Watts: in the timings, there are two sets of timing (second set following the "Differences from previous clusterpush", but the 'current' times are different. Is this expected ? | 18:34.02 |
| Robin_Watts | I'm guessing here, but it's maybe only calculating the 'current' time from the files that were in both sets of results (and didn't time out). | 18:35.24 |
| ray_laptop | ps.psdcmyk GS_CLIENT_COLOR_MAX_COMPONENTS 32 is 24:03 (41% hit) | 18:35.44 |
| Robin_Watts | mvrhel: ping | 18:39.42 |
| | Just looking to update the doc/Devices.htm file sections on tiffsep and psdcmyk with -dMaxSpots. | 18:40.10 |
| mvrhel | yes that needs to be done | 18:40.28 |
| | we probably need to do some other updates in there | 18:40.38 |
| Robin_Watts | the existing text looks like it's not been updated with the planar stuff? | 18:40.44 |
| mvrhel | yes | 18:40.49 |
| | you just reminded me of this | 18:40.54 |
| Robin_Watts | (sorry, phone went, hence lag). | 18:40.56 |
| mvrhel | all the compressed color stuff needs to go | 18:41.04 |
| Robin_Watts | Do you want to update that and then I'll add -dMaxSpots on afterwards ? | 18:41.25 |
| | or do you want me to have a crack at it now ? | 18:41.37 |
| ray_laptop | 64 is taking a LOT longer -- bet we picked up some timeouts | 18:44.00 |
| mvrhel | Robin_Watts: I will go ahead and try to tackle that today | 18:45.54 |
| Robin_Watts | ok. We DO still get the warning about "Max spot colorants reached". | 18:46.15 |
| ray_laptop | ps.psdcmyk GS_CLIENT_COLOR_MAX_COMPONENTS 64 is 44:03 (83% hit over 32, 257% hit over 14) so, as expected, pdf.psdcmyk from 32 to 64 GS_CLIENT_COLOR_MAX_COMPONENTS made no difference, but PS _REALLY_ needs -dMaxSpots. I suggest 10 | 18:46.16 |
| | how much does a timeout ding the total (64 had 3, 32 had 1, 14 had none) ? | 18:47.04 |
| Robin_Watts | runs that timeout count as the timeout value. | 18:47.32 |
| ray_laptop | I just didn't know what the timeout value is | 18:47.58 |
| Robin_Watts | so the timings are better than they should be (no way to tell by how much) | 18:48.01 |
| | 5 minutes? | 18:48.04 |
| mvrhel | Robin_Watts: I will check out about the warning and add in what we need there too | 18:48.29 |
| Robin_Watts | Trying to see if there is a simple way to figure out how to improve that warning. I think I'll leave it to you :) | 18:49.04 |
| mvrhel | I have to head out in a bit to the dentist and then take the car back to the shop. | 18:49.11 |
| ray_laptop | well, it ran 834 jobs in 279 seconds at 32 (with one timeout) so I don't think it is 5 minutes | 18:49.18 |
| mvrhel | Robin_Watts: that is fine | 18:49.21 |
| Robin_Watts | mvrhel: Sounds like a fun filled day for you :) | 18:50.11 |
| ray_laptop | Can we agree that MaxSpots 10 is good ? | 18:50.15 |
| Robin_Watts | Sure. | 18:50.25 |
| mvrhel | Robin_Watts: yes. just great. | 18:50.44 |
| ray_laptop | mvrhel: ? your opinion (you've seen more sep files -- any real world PS files ?) | 18:50.59 |
| mvrhel | ray_laptop: I think 10 is fine for PS | 18:51.20 |
| | I have not seen a PS file come in with spots in a long time | 18:51.38 |
| ray_laptop | Robin_Watts: I'll leave the commit to you then, unless you want me to | 18:51.54 |
| Robin_Watts | I think with the warning, 10 is fine. People won't (shouldn't) be caught out. | 18:51.55 |
| | I'll commit it, if mvrhel is happy to mention -dMaxSpots in his doc update later? | 18:52.25 |
| | (or I can follow up with that afterwards) | 18:52.38 |
| ray_laptop | I'll have a go with ripping out icclib, then | 18:52.51 |
| Robin_Watts | Do we want the constant planes compression patch in ? | 18:53.00 |
| mvrhel | Robin_Watts: yes I will add that | 18:53.01 |
| ray_laptop | Robin_Watts: yes, please | 18:53.13 |
| Robin_Watts | Committed/Pushed | 18:53.39 |
| ray_laptop | Robin_Watts: thanks | 18:53.49 |
| Robin_Watts | mvrhel: Thanks. | 18:53.50 |
| ray_laptop | Robin_Watts: is there any technical reason someone couldn't use gs on ipad ? | 18:57.01 |
| | scott-san has an interest. | 18:57.17 |
| Robin_Watts | Urm... | 18:57.17 |
| | I can't think of one. | 18:57.36 |
| ray_laptop | they want jpeg and png output | 18:57.42 |
| Robin_Watts | Hmm. File output is 'interesting' on iOS. | 18:58.00 |
| | But tor8/paulgardiner may know more than me. | 18:58.32 |
| | ray_laptop: Why gs, not mupdf? | 18:58.50 |
| | For ps I guess. | 18:58.56 |
| ray_laptop | Robin_Watts: does mupdf support jpeg and png output ? | 19:00.12 |
| Robin_Watts | png certainly. | 19:00.19 |
| | jpeg would be easy to add. | 19:00.24 |
| | mudraw produces pngs by default. | 19:00.56 |
| | (also ppm, pgm) | 19:01.07 |
| | (and pbm) | 19:01.11 |
| | Essentially we create an rgb bitmap and can compress it any way we like. | 19:06.43 |
| ray_laptop | Robin_Watts: thanks -- I told Scott, pointing out that mupdf supports xps AND pdf, gs supports ps AND pdf, so pick and choose. The footprint of gs (stripped down build) is a bit larger, but not a killer | 19:07.41 |
| | Robin_Watts: I noticed in your change MAX_COMPONENTS_IN_DEVICEN is still 32 -- was that intentional. Also the log message says the "default" is (GS_CLIENT_COLOR_MAX_COMPONENTS-4) but it is set to 10 (as we agreed) | 20:35.31 |
| Robin_Watts | MAX_COMPONENTS_IN_DEVICEN - yes. | 20:35.56 |
| | That matches Acrobat. | 20:36.03 |
| | The log message is my screwup. | 20:36.14 |
| ray_laptop | Robin_Watts: but it doesn't match PostScript (PLRM has a limit of 252) I think we should just have them the same | 20:37.08 |
| Robin_Watts | That's one for mvrhel to weigh in on. | 20:37.40 |
| ray_laptop | AFAIK, only the CET tries to set up a colorspace with the max | 20:38.23 |
| mvrhel_laptop | ray_laptop: AR limits MAX_COMPONENTS_IN_DEVICEN to 32. Since we used to have this the same as GS_CLIENT_COLOR_MAX_COMPONENTS I am wondering how we every could have passed the CET test you mention | 22:35.25 |
| | Forward 1 day (to 2012/08/03)>>> | |
IRC Logs