| | <<<Back 1 day (to 2012/04/24) | 2012/04/25 |
| rayjj | Robin_Watts: I saw your timings in the logs. What are the specs on your ARM board (beagleboard?) | 02:15.17 |
| rayjj | is hoping that it is < 1.2GHz | 02:16.04 |
| mvrhel_laptop | hi marcosw | 05:51.48 |
| | just got into curpertino | 05:51.56 |
| marcosw | hi mvrhel_laptop, you arrived late, I thought you were coming in this afternoon. | 05:52.21 |
| mvrhel_laptop | too much going on at home so I had booked a late flight which left at 7:40 | 05:53.03 |
| | especially since I am leaving again Saturday.... | 05:53.16 |
| | rode in a stretch limo from the airport to the hotel | 05:53.57 |
| | I think I can walk to apple from here | 05:54.04 |
| marcosw | there is a lot going on at my house too. my wife left this morning on a business trip and returns late Saturday. Sunday is my daughter's 15th birthday party and that evening I'm flying out. | 05:55.54 |
| mvrhel_laptop | I see the meeting is in the Beatles room. | 05:56.55 |
| marcosw | presumably all of the meeting rooms are named after bands, the | 05:57.45 |
| | small the meeting room the more obscure the band? | 05:57.54 |
| mvrhel_laptop | perhaps | 05:58.03 |
| | looks like a good list of attendees | 05:58.20 |
| | about 26 or so | 05:58.25 |
| | so the meeting is not in the infinite loop area but next door | 06:02.26 |
| | ok. see you in the morning marcosw | 06:05.03 |
| marcosw | mvrhel_laptop: see you tomorrow, nigh. | 06:05.29 |
| kens | For the logs Robin_Watts can you ping me when you've finished your run please ? | 08:24.22 |
| Robin_Watts | ping | 09:19.00 |
| kens | Morning Robin | 09:19.06 |
| | Hvae you got a few minutes ? | 09:19.12 |
| Robin_Watts | Sure. | 09:19.44 |
| kens | OK Its Memento | 09:19.49 |
| Robin_Watts | ray_laptop: (For the logs) 600 MHz | 09:19.56 |
| kens | It is telling me that a block of memory is not free, but I can see me explcitly freeing it. | 09:20.07 |
| | Now I need to know if its really free, so I need to see why Memento thinks its not, any ideas ? | 09:20.34 |
| Robin_Watts | Memento keeps 2 lists of blocks. | 09:21.19 |
| | An in use list, and a freed list. | 09:21.34 |
| kens | OK | 09:21.52 |
| Robin_Watts | When it sees a free, blocks move from the in use list to the free list. | 09:21.57 |
| | When the free list gets bigger than a certain size, we start to really free the blocks in it. | 09:22.16 |
| | The idea being that we can watch for free blocks being written to for a while after they are freed. | 09:22.41 |
| kens | Fair enough | 09:22.48 |
| Robin_Watts | also, on a free, we fill the block with a preset value. | 09:22.52 |
| kens | Hmm, I'm not certain this is happening, but I haven't checked | 09:23.09 |
| Robin_Watts | I have been meaning to add the facility so that you can stop when a given block is freed. | 09:23.52 |
| kens | Well, I can do that anyway in this case, I know when the free takes place. | 09:24.16 |
| | 'my' freee. | 09:24.24 |
| | Rather than a real free | 09:24.32 |
| Robin_Watts | If you call Memento_find(address) then it will tell you what block that address is in (Including whether it's a freed block or not) | 09:25.20 |
| kens | OK I'll try that | 09:25.35 |
| | I need to add this to my code presumably ? | 09:26.15 |
| Robin_Watts | I call it from the Quickwatch window (Alt-Ctrl-Q) | 09:27.30 |
| kens | Hmm didn't work for me | 09:27.40 |
| Robin_Watts | Though if you're just entering a number for the address you need to (void *) it. | 09:27.50 |
| | Memento_find((void *)12345) | 09:27.59 |
| kens | Ah, maybe that was it | 09:28.13 |
| | OK gives me a value (13607) type int | 09:29.53 |
| Robin_Watts | and look in the console window. | 09:30.17 |
| kens | Yes just saw that | 09:30.23 |
| Robin_Watts | That's the block number. | 09:30.26 |
| kens | Yes,c orrect | 09:30.33 |
| | Says its 'in preguard of allocated block' now to continue to the free | 09:30.47 |
| Robin_Watts | Ah, well, that's the key. | 09:30.59 |
| kens | ? | 09:31.04 |
| | THat's the memory returned from 'alloc' inside Memento | 09:31.15 |
| | SO I exepct that | 09:31.21 |
| Robin_Watts | Oh, ok. | 09:31.29 |
| kens | Hmm, now that is itnerstgin, the code seems to have lost track of that memory altogether (not Memento, pdfwrite) | 09:32.10 |
| | Looks like more digging required. Thanks Robin | 09:32.24 |
| Robin_Watts | no worries. | 09:32.30 |
| naveen_ | Hi Robin,Morning | 09:38.15 |
| Robin_Watts | Morning naveen_ | 09:41.22 |
| naveen_ | just want to update you that I got muPDF working with the suggestions you provided... | 09:42.05 |
| Robin_Watts | Excellent! | 09:42.12 |
| | What's the performance like? | 09:42.34 |
| | I could believe that you'd need to do some caching and maybe decrypt sections of blocks to get the performance up | 09:43.17 |
| naveen_ | I have modified the logic to decrypt only when the current block is not decrypted...do you want to have a look at the code? | 09:44.15 |
| Robin_Watts | no, as long as you're happy. | 09:44.31 |
| | The key thing is to know that if performance turns out to be a problem, there are still things you can do to improve it. | 09:44.52 |
| naveen_ | performance wise I don't see any difference between the plain file & our encrypted file.. | 09:45.09 |
| Robin_Watts | oh, well that's great. | 09:45.37 |
| naveen_ | do you have any suggestions for performance improvement that you think are good to do? | 09:46.34 |
| Robin_Watts | If you're getting the same performance as the plain file, then I wouldn't do anything. | 09:47.26 |
| | No point in optimising when you're fast enough already. | 09:47.36 |
| | If in the future it ever becomes an issue, come back to me. | 09:47.47 |
| naveen_ | you are the one I'll catch you for sure :) | 09:48.14 |
| | one thing i noticed is that the pdf is opening from some arbitrary page...not from 1 page...do you see any reason for this? | 09:49.41 |
| Robin_Watts | no, that's odd. | 09:50.06 |
| naveen_ | actaully in open_encrypted_file function,I seek through the file to read the header..but set it back to file start...does this have any impact | 09:50.59 |
| Robin_Watts | shouldn't do - the pages aren't stored in linear order in a PDF file. | 09:51.37 |
| naveen_ | actually it looks like it is remembering the last opened document position.. | 09:55.21 |
| | ok...I'll try to figure it out... | 09:57.32 |
| | Thanks for all the help Robin, without your help i wouldn 't be able to do this..... | 10:00.09 |
| Gigs- | rayjj: are you the ray? | 13:04.52 |
| kens | He won't be here, he's in LA, so its early morning | 13:05.17 |
| Gigs- | oh | 13:05.20 |
| | you know much about tiffsep? | 13:05.27 |
| kens | I know its changing :-) | 13:05.38 |
| Gigs- | hehe | 13:05.40 |
| Robin_Watts | Gigs: We are familiar with bits of it. What do you want to know? | 13:05.56 |
| Gigs- | There seems to be a regression or something in the version in 9.05 | 13:06.09 |
| | http://pastebin.ca/2139894 | 13:06.11 |
| | When I specify only Varnish in the SeparationOrder, nothing gets rendered | 13:06.23 |
| kens | Wasn't there a thread on this in the logs last night ? | 13:06.45 |
| Gigs- | Kind of | 13:06.50 |
| | I didn't know at that point what specifically was happening | 13:07.01 |
| | ray explained some of the changes to me | 13:07.10 |
| Robin_Watts | Isn't varnish just a colorless spot ? | 13:07.12 |
| kens | I assume the PostScript actually contains some marking operations in the Vrarnish spot colour | 13:07.18 |
| Gigs- | it's a spot that is usually either flood filled or a simple rectangle | 13:07.33 |
| Robin_Watts | I am not familiar with SeparationOrder, so I'm going to back out of this, sorry. | 13:07.51 |
| Gigs- | ok | 13:07.56 |
| Robin_Watts | lunchtime. | 13:08.01 |
| Gigs- | SeparationOrder seems to be working otherwise to supress rendering of one or two CMYK colorants | 13:08.15 |
| | kens SeparationOrder seems to be working otherwise to supress rendering of one or two CMYK colorants | 13:08.20 |
| | if I leave out Cyan for example it does seem to supress that output and render the rest of the colors fine | 13:08.35 |
| kens | Sorry, my IRC client crashed | 13:08.39 |
| | SeparationOrder needs to match SeparationNames | 13:08.59 |
| | As regards number of inks | 13:09.06 |
| Gigs- | if you want everything to render, yes | 13:09.08 |
| kens | If an ink isn't mentioned in SeparaionInks then it will be tint transformed | 13:09.25 |
| Gigs- | what I do is specify all the colorants in separationColorNames and then leave some out in seperationorder in order | 13:09.50 |
| | in order to supress rendering selectively | 13:10.00 |
| | this still works for supressing blank CMYK channels for example | 13:10.16 |
| kens | Hmm, I'd have to read the red book, but I don;t see why leacing them out of the order would suppress them | 13:10.20 |
| Gigs- | I think it might be a tiffsep thing more than a PS thing | 13:10.33 |
| kens | Possibly its a bug | 13:10.49 |
| Gigs- | the ability to suppress them by leaving them out is intended | 13:11.13 |
| kens | But the SpearaionNames etc are part of standard PS | 13:11.14 |
| | Gigs, in that case you know more than I do | 13:11.26 |
| Gigs- | heh ok | 13:11.30 |
| | Is dan still at artifex | 13:11.47 |
| kens | Nope | 13:11.52 |
| Gigs- | I guess I need to wait for ray then or mvrhel | 13:12.22 |
| kens | Probably ray | 13:12.29 |
| Gigs- | yeah I rarely see mvrhel on irc | 13:12.41 |
| kens | He's here but he is alos West Coast US | 13:12.53 |
| Gigs- | anyway I have a workaround at this point, it's not too pretty but it's OK | 13:13.38 |
| | I just have to render all the separations a second time to get only the Varnihs | 13:13.50 |
| | varnish | 13:13.53 |
| | the first render supresses only the varnish so that it doesn't get overprinted over the composite | 13:14.36 |
| | some background just FYI... varnish is often inserted as a Separation in prepress files because it's imaged on a plate as if it were an ink. But the varnish is actually clear. Often the artists will give it a tint so they can see it, and in prepress software it's easy enough to toggle off channel | 13:17.31 |
| | so when you render the actual overprinted image you need to either override its tint transform so it doesn't cover up the entire label or supress its rendering entirely | 13:18.31 |
| | entire image, sorry. I mostly work with offset printed labels :) | 13:19.38 |
| kens | To be honest my usual approach is to set up a CMS to send named separations to C+M+Y+K-0 | 13:21.41 |
| | C=M=Y=K=0 | 13:21.50 |
| | But that was in a former life | 13:22.05 |
| naveen_ | Hi Robin, will mupdf works on mac? | 13:34.24 |
| kens | yes | 13:35.18 |
| | as far as I know | 13:35.24 |
| Laibsch | How can I suppress the "GS>" prompt when running "gs -q -dNOPAUSE -dSAFER=true -sDEVICE=tiffg3 -sPAPERSIZE=a4 -dFIXEDMEDIA -r204x196 -sOutputFile=/tmp/output.tif /tmp/sample_greyscale.pdf"? | 13:44.15 |
| kens | -dBATCH | 13:44.23 |
| | or use -o | 13:45.05 |
| Laibsch | works like a charm, muchas gracias | 13:45.28 |
| kens | NP | 13:45.32 |
| Laibsch | what does -o do? can't find it in "gs --help" or the man page. | 13:46.42 |
| | output file? | 13:46.49 |
| Robin_Watts | naveen_: Sure does. | 13:46.55 |
| kens | Yes, like -sOutptuFile, but it incorporates BATCH and NPAUSE | 13:47.13 |
| Laibsch | cool, thanks | 13:47.22 |
| Robin_Watts | It's just struck me... mvrhel is Apple today, having a meeting in the "Beatles" room. Do they name all their rooms after people that have sued them ? | 14:14.53 |
| kens | They will have a wider choice available now | 14:15.19 |
| | Hee the 2012 Turing test will be held at Bletchley Park in Alan Turing's office. | 14:16.16 |
| sebras | kens :-D | 15:52.03 |
| kens | ? | 15:52.12 |
| sebras | meeting room names. | 15:52.36 |
| kens | Ah :-) | 15:52.43 |
| marcosw | morning mvrhel_laptop | 16:08.56 |
| mvrhel_laptop | morning marcosw | 16:09.07 |
| Robin_Watts | mvrhel_laptop: We were wondering if all the meeting rooms at apple were named after people that have sued them ? | 16:10.36 |
| | If so, presumably samsung have a whole wing of the building. | 16:11.07 |
| kens | And Motorola ? | 16:11.25 |
| | Also that new academic with teh touch screen patent | 16:11.40 |
| Robin_Watts | And they'll be planning a new google campus :) | 16:11.58 |
| mvrhel_laptop | funny | 16:18.02 |
| | Robin_Watts: I have isolated my rendering issue. I am hoping to have that solved today/tonight and then I will focus on the segvs | 16:20.44 |
| Robin_Watts | mvrhel_laptop: Cool. | 16:20.54 |
| | I've pushed at least one thing to master that should remove a couple of them. | 16:21.06 |
| mvrhel_laptop | thanks | 16:21.22 |
| Robin_Watts | I'm tinkering in mupdf at the mo - let me know if you have things you want looked at. | 16:22.11 |
| mvrhel_laptop | ok | 16:22.17 |
| Gigs- | mvrhel_laptop: hi | 16:22.29 |
| | mvrhel_laptop: do you have a minute to discuss tiffsep | 16:22.37 |
| mvrhel_laptop | Gigs: Hi. unfortunately not right now. In a meeting and I have to give a talk in a bit | 16:23.08 |
| Gigs- | ok | 16:23.11 |
| mvrhel_laptop | but I saw you dicussion with ray_laptop earlier and would like to talk with you about this topic since I am getting close to finishing things | 16:23.46 |
| Gigs- | ok, thanks | 16:23.56 |
| ray_laptop | Robin_Watts: thanks for the timings. since your clock rate is 1/2 of his and you are getting about the same time, something is fishy. | 16:32.04 |
| Robin_Watts | I'm also running from an SD card. | 16:32.43 |
| ray_laptop | but it may be the fonts he is using are more difficult to load | 16:32.45 |
| | Robin_Watts: right. He mentioned a HDD which on a eval board may not be very fast | 16:33.18 |
| | loading the fonts from HDD might be his bottleneck. I'm going to suggest he try with them compiled in. He has plenty of RAM | 16:34.32 |
| | Gigs: I saw your comments/questions in the logs. Probably you need to send a file so we can see the issue with Varnish not coming out. | 16:35.51 |
| Gigs- | OK | 16:36.10 |
| | it's customer data so I will need someone to mark the attachment private | 16:36.22 |
| ray_laptop | I just managed to reproduce a strange problem from cust 532. If I set a transfer function prior to running a file, it slows down by 16x (with HEAD and their old 8.7x code). Spends a lot of time allocating TF arrays that then eventually have to get GC'ed. Now to figure out why | 16:38.36 |
| | Gigs: if it is private data, you can just send it via email | 16:39.07 |
| Gigs- | We've done it on bugzilla before with marking it private | 16:39.19 |
| | actually I think I have rights to mark things private now | 16:39.26 |
| ray_laptop | Gigs: OK | 16:39.36 |
| Gigs- | To be clear ray the issue is that if I only specify Varnish and nothing else in SeparationOrder then I get blank output | 16:39.42 |
| | if I leave out say Cyan then Cyan is indeed supressed | 16:39.54 |
| | and the rest render | 16:39.58 |
| ray_laptop | bugzilla now lets you mark it private when you attach the file. It used to require a separate step which left a time during which it was not private | 16:40.29 |
| Robin_Watts | ray_laptop: It may be that only we get the option to mark things private. | 16:40.53 |
| ray_laptop | Gigs: blank output or no separation file ? | 16:41.05 |
| Gigs- | it used to be that way but I think I have the rights now | 16:41.11 |
| | I get a single output file that is named like the composite and it's large, but blank | 16:41.24 |
| | larger than a blank file should be | 16:41.36 |
| | anyway let me put in the bug report | 16:41.48 |
| ray_laptop | Gigs: I think that by default tiffsep doesn't compress. You have to specify -sCompression=___ e.g. -sCompression=lzw | 16:43.34 |
| | Gigs: Thanks. | 16:44.01 |
| Gigs- | actually I can't seem to mark attachments private anymore | 16:50.00 |
| | ray_laptop: http://bugs.ghostscript.com/attachment.cgi?id=8550&action=edit | 16:50.07 |
| | mark private sometime soon please | 16:50.21 |
| Robin_Watts | Gigs: I've marked it private. | 16:50.25 |
| Gigs- | thanks | 16:50.27 |
| ray_laptop | Robin_Watts: thanks | 16:50.29 |
| Robin_Watts | np. | 16:50.37 |
| Gigs- | http://bugs.ghostscript.com/show_bug.cgi?id=693004 is the bug link | 16:50.43 |
| chrisl | Gigs-: what happens if the SeparationColorNames and SeparationOrder are the same? | 16:51.37 |
| ray_laptop | Gigs: BTW, if you have a file with lots of separations and transparency, mvrhel might like to have it for performance testing. | 16:51.40 |
| Gigs- | chrisl: then it renders them all correctly | 16:51.56 |
| | also it seems to work if you say suppress Cyan with SeparationOrder | 16:52.11 |
| | for some reason when it's Varnish alone that's when it doesn't work | 16:52.33 |
| | I haven't tested to see if the same is true of other spot colors | 16:52.56 |
| | ray_laptop: ok | 16:53.17 |
| chrisl | Is the a reason not to have to two arrays the same? | 16:53.53 |
| Gigs- | separations not specified in SeparationOrder are not rendered | 16:54.13 |
| | originally it was kind of a workaround for the 8 colorant limitation | 16:54.24 |
| | you had to do multiple passes, specifying 8 colors at a time in SeparationOrder | 16:54.44 |
| | and then merge the results yourself | 16:54.54 |
| | I also use the feature to avoid rendering Varnish separations overtop of my images | 16:55.43 |
| | then I need to go back and generate the Varnish by itself | 16:55.52 |
| chrisl | Presumably if you only have one entry in the names array, oveprint doesn't work..... | 16:56.21 |
| Gigs- | you mean in the Order? | 16:57.05 |
| chrisl | Names | 16:57.20 |
| Gigs- | the names array must always contain the entire list of separations, from what I understand | 16:57.22 |
| ray_laptop | WOW. 7029 garbage collections during a single page | 16:59.04 |
| Gigs- | is that mine? | 16:59.10 |
| ray_laptop | Gigs: no, cust 532 | 16:59.18 |
| Gigs- | Now that the colorant limitation is gone, a feature that would override the tint transform of a separation to cause it to not print would actually suit me better | 16:59.43 |
| chrisl | ray_laptop: lots of little images, or little shaded fills? | 16:59.59 |
| Gigs- | sounds like a postscript conversion... forced language level crap | 17:01.12 |
| | that causes a big mess | 17:01.17 |
| | I'm glad we don't deal with much postscript these days | 17:01.42 |
| Robin_Watts | tor8: hey | 17:04.04 |
| | In mupdfclean can we do the retainpages before the preloadobjstreams ? | 17:04.25 |
| chrisl | Gigs: do you have idea how long this problem has been around? Like, did it come in when we switched to libtiff for the tiff output? | 17:05.57 |
| Gigs- | somewhere between late 8 and 9.05 | 17:10.54 |
| | it had been a while since I upgraded | 17:11.04 |
| | probably 1.5 year old SVN snapshot | 17:11.22 |
| chrisl | It might be something I did then, let me have a look..... | 17:12.36 |
| ray_laptop | Gigs: on your file, I see it setting "CS10" colorspace, then "1 scn" (100% colorant) then "40.486 40.5 666 312.75 re f" to paint a rectangle | 17:12.43 |
| | Gigs: CS10 is the Varnish separation | 17:13.08 |
| Gigs- | What does that mean? | 17:14.22 |
| ray_laptop | Gigs: just processing all the separations gives a valid CMYK composite (the tint transform for Varnish is OK so it doesn't affect the composite) | 17:18.09 |
| Gigs- | yeah, in this case | 17:18.24 |
| chrisl | Gigs: when I run your command line with your file I get an output file called "buildtiffs_3.s4.tif" - your report suggests you don't see that? | 17:18.29 |
| Gigs- | chrisl: that's correct | 17:18.43 |
| ray_laptop | The "DIE" tint transform, however is black, so the lines appear on the composite CMYK | 17:18.45 |
| chrisl | Gigs: so we're seeing different behaviour? | 17:18.59 |
| ray_laptop | chrisl: are you running 9.05 or HEAD ? | 17:19.13 |
| chrisl | ray_laptop: I'm running HEAD right now | 17:19.40 |
| ray_laptop | chrisl: could be we fixed something. | 17:20.55 |
| | it's been known to happen ;-) | 17:21.07 |
| Gigs- | I'm sorry that's wrong | 17:21.07 |
| | I get s4 | 17:21.12 |
| | but it's blank | 17:21.14 |
| ray_laptop | Gigs: when I run with all separations, s4 is a black rectangle that fills top to bottom, from the left edge to where the inner right line on the DIE layer | 17:22.39 |
| Gigs- | yeah, that's correct rendering | 17:22.57 |
| ray_laptop | Gigs: what do you see on s4 if you just run with: gswin32c -r144 -sDEVICE=tiffsep -o Bug693004.tif Bug693004.pdf | 17:23.52 |
| Gigs- | the rectangle | 17:24.11 |
| ray_laptop | i.e., let it automatically include all separations | 17:24.14 |
| Gigs- | interestingly, it renders s4 right if you include cyan | 17:24.51 |
| ray_laptop | Gigs: OK. I'm trying your command line variation (only Varnish) now. (since chrisl didn't say what he got) | 17:24.52 |
| Gigs- | /SeparationOrder [ (Varnish) (Cyan) ] produces expected output | 17:25.15 |
| chrisl | ray_laptop Gigs: I saw blank output in the s4 file | 17:25.56 |
| ray_laptop | Gigs: what about two separations such as [ /Blue /Varnish ] ? | 17:26.04 |
| | chrisl: thanks, I won't bother then | 17:26.14 |
| Gigs- | I believe Blue is supposed to be blank | 17:26.19 |
| | but yes that causes Varnish to render correctly as well | 17:26.27 |
| ray_laptop | Gigs: yes, it is | 17:26.29 |
| | Gigs: looks like a bug. | 17:26.45 |
| Gigs- | whooo that's weird | 17:27.06 |
| | /SeparationOrder [ (Cyan) ] looks all messed up | 17:27.22 |
| ray_laptop | Gigs: well, at least you have a temporary work around | 17:27.35 |
| Gigs- | it looks like only rendering one separation is broken no matter what it is | 17:27.56 |
| | it's a blocky mess if you specify only magenta or cyan | 17:28.26 |
| ray_laptop | Gigs: since you have a way to work around the problem, we'll probably wait until mvrhel drops in his (massive) changes to do planar spot color for tiffsep and psdcmyk | 17:28.37 |
| Gigs- | ok | 17:28.42 |
| ray_laptop | there is a chance (with so many changes) that it will have been fixed by fortunate accident | 17:29.42 |
| tor8 | Robin_Watts: why? | 17:29.55 |
| ray_laptop | is overly optimistic sometimes | 17:30.00 |
| chrisl | ray_laptop: even if it's not already fixed, it's pointless to investigate when the code is likely to change imminently...... | 17:31.22 |
| ray_laptop | chrisl: right. | 17:33.48 |
| Robin_Watts | tor8: I'm playing with the internals of pdfclean, to try to move more of it into the library. | 17:33.55 |
| | (Specifically, I want to move the 'write out this pdf file' into the lib) | 17:34.09 |
| ray_laptop | Gigs: I added a comment to the bug to capture what we just discussed and also added mvrhel to the cc list | 17:37.53 |
| | Robin_Watts: presumably that'll be handy to save updated or flattened forms ? | 17:38.51 |
| Robin_Watts | ray_laptop: That's my reason for doing it. | 17:39.10 |
| | (or my excuse at least) | 17:39.13 |
| Gigs- | ray_laptop: yeah I kind of made a mess of the bug. I'm too used to jira where you can edit everything | 17:39.52 |
| ray_laptop | Gigs: the good news for you is that we have a supported customer (393) that uses tiffsep and has given us several challenging files, and provided the impetus for mvrhel to develop the way of handling > 8 colorants without compressed encoding. Performance should be better, and a LOT better if the page has transparency | 17:43.52 |
| Gigs- | That's cool... looks like my little NRE seed investment turned out well for you all in the end hehe | 17:44.26 |
| | it is pretty handy in the prepress environment | 17:44.48 |
| ray_laptop | Gigs: I forget what project that was, but thanks. | 17:45.10 |
| | Gigs: we'll have to ask mvrhel, but there may be a way for you to use one of the ICC profiles in order to address the Varnish issue (use a colorless ICC profile instead of the tint transform in case it is problematic). | 17:47.25 |
| | Gigs: I'm not sure from the docs, but the -sNamedProfile=___ looks like it might. | 17:48.27 |
| Robin_Watts | tor8: Just spotted the first bug in 1.0 :) | 17:48.37 |
| Gigs- | it would be ideal if I could suppress the rendering in the composite but still have it render in the separations, but that might not be possible | 17:48.43 |
| Robin_Watts | The usage message for mupdfclean still refers to itself as pdfclean. | 17:48.49 |
| Gigs- | otherwise it's still a two pass deal in which case it wouldn't be much improvement over SeparationOrder | 17:49.27 |
| tor8 | Robin_Watts: right. I don't think the preloadobjstms should matter, but my memory of the details of pdfclean are hazy | 17:49.32 |
| Robin_Watts | tor8: I agree. I can't see how it'd matter. | 17:49.49 |
| ray_laptop | Gigs: we'll wait and chat with mvrhel. He's at the OpenPrinting meeting today (giving a talk on ghostscript's color management for printing) | 17:49.50 |
| Gigs- | ok thanks | 17:49.58 |
| sebras | Robin_Watts: beware of doing -ggg in pdfclean though. I think I may have forgotten to fix that before 1.0... | 17:51.25 |
| ray_laptop | I hope they are not being mean to mvrhel -- there were a few folks that really objected to ghostscript's capability to override the ICC profile in the PDF. Several flames going back and forth on the subject | 17:51.45 |
| Gigs- | It's not an unusual function | 17:52.23 |
| kens | Off folks, goodnight | 17:54.53 |
| ray_laptop | bye, kens | 17:55.09 |
| Robin_Watts | mvrhel_laptop: Hey. How'd it go? | 18:18.36 |
| mvrhel_laptop | hi Robin_Watts: it went well. had a few questions | 18:19.46 |
| Robin_Watts | mvrhel_laptop: A few questions is good. | 18:51.18 |
| | None mean that you lost everyone completely. Too many means you made no sense :) | 18:51.37 |
| mvrhel_laptop | yes | 18:52.11 |
| oy | mvrhel_laptop: thanks for your talk | 19:02.57 |
| mvrhel_laptop | oy. thank you for yours | 19:03.12 |
| oy | not shure, if I was spot on | 19:03.43 |
| mvrhel_laptop | it was good to get the exposure | 19:03.55 |
| oy | but it is nice to see how GS and OpenICC implement on the PDG CM stuff, moving stuff in a good direction IMO | 19:04.49 |
| | *PDG CM stuff | 19:05.06 |
| mvrhel_laptop | yes | 19:05.18 |
| oy | sorry, it is too late :-D *PDF CM stuff | 19:05.42 |
| ray_laptop | hi mvrhel_laptop: Glad your talk went well. | 19:07.58 |
| mvrhel_laptop | hi ray_laptop | 19:08.12 |
| ray_laptop | mvrhel_laptop: did you see the strange problem from Gigs in the logs (bug 693004) | 19:08.19 |
| | if you get a chance you can try a single separation with tiffsep on your (almost there) code, but I would NOT hold up your commit if it is still broken | 19:10.08 |
| mvrhel_laptop | I saw the bug, but I have not had a chance to look at it. I am focused on getting the last rendering and segv issues. I do need to do some testing with the command line options for color separations | 19:11.29 |
| ray_laptop | mvrhel_laptop: if there is a DeviceN profile that has color names, does it get used instead of the tint transform for a spot color (related to the discussion about "Varnish" above -- Gigs wants it to be colorless in the composite CMYK without affecting the separation plane) | 19:13.43 |
| mvrhel_laptop | ray_laptop: that would be possible, but we really should be fine without that approach | 19:15.47 |
| ray_laptop | mvrhel_laptop: I was curious if there was a way to finagle the ICC profiles to "fix" the common problems of 'meta' layers having tint transforms that mess up the composite view | 19:16.03 |
| | mvrhel_laptop: Gigs has some files where the creator colored the Varnish layer (so they could see it) and that messed up the composite | 19:17.22 |
| mvrhel_laptop | oh. so the tint transform is actually bad for the varnish colorant. i.e. it is not clear | 19:17.28 |
| Robin_Watts | ray_laptop: But that's not the central issue with Gigs bug though, right? | 19:17.54 |
| ray_laptop | mvrhel_laptop: right. In the file attached to the bug it is fine, but sometimes it is problematic. | 19:17.55 |
| Robin_Watts | The central issue with the bug, AIUI, is that if we select JUST to render a single component (in this case Varnish), it comes out blank. If it's rendered in combination with other colorants, it comes out fine. | 19:18.53 |
| ray_laptop | Robin_Watts: right. The bug is something he tripped over when trying to generate the Varnish layer all by itself | 19:18.56 |
| Gigs- | well it comes out blank in the case of the varnish, but it's garbled if it's got real data on it apparently | 19:19.41 |
| | when you try to isolate Cyan for example it produces a mess | 19:20.01 |
| mvrhel_laptop | ok. well I will take a look at this before we do the big commit. I have tracked down my clist issue or at least narrowed it down to the offending command. | 19:20.18 |
| ray_laptop | but if he can get the Varnish separation along with the other separations in a single pass, it is more efficient and easier, as long as the tint transform for the 'meta' layers can be rendered as clear in the composite | 19:20.24 |
| | mvrhel_laptop: I don't think you need to do this before your commit. | 19:21.00 |
| | hi, Gigs: I hope I'm expressing the issue correctly | 19:21.46 |
| Gigs- | yeah | 19:21.54 |
| ray_laptop | if we can't do it with ICC profiles, then just adding an option that lets the user specify a list of colorants to exclude from the composite CMYK would be easy enough. somethng like -sExcludeColorFromCMYK=/Varnish/Die/Lamination | 19:25.53 |
| | name and syntax NOT the best, maybe | 19:26.26 |
| | oops. phone call... bbiab | 19:26.44 |
| debjan | Hi. Let me congratulate on MuPDF 1.0 release. | 19:47.57 |
| | Not to be ungrateful, but I downloaded and build it on Ubuntu today, and got an idea which I wanted to propose. However Google Code project issues (enhancement/defect) does not exist, but only link to bugzilla. Is there any proper place I can post sort of "feature request"? | 19:47.57 |
| Robin_Watts | debjan: Go to bugs.ghostscript.com and open an enhacement bug. | 19:48.21 |
| | or an enhancement bug, even. | 19:48.30 |
| debjan | OK, thanks | 19:48.36 |
| Robin_Watts | debjan: What's the enhancement then? | 19:48.54 |
| debjan | About grid display | 19:49.09 |
| Robin_Watts | tor8: For your delight and delectation... On my repo on casper, there are 2 commits. The first is the reworking to make pdfclean live within the library. | 19:49.13 |
| debjan | Do you want me to post it here also | 19:49.17 |
| Robin_Watts | debjan: This a viewer feature request ? | 19:49.34 |
| debjan | Yes | 19:49.39 |
| Robin_Watts | mentioning it on here is a good idea, because we can give you instant feedback. | 19:49.48 |
| debjan | I'll paste it | 19:50.14 |
| | I would like to propose this idea: allow page display grid in 2 columns. | 19:50.20 |
| | Let's assume shortcut 'p' is assigned to this grid action - if user presses '2p' then view screen to be split on on two (1x2) pages (similar to 'book view'). If user presses '8p' split view screen to 8 (2x4) pages (similar to 'page thumbs'). If user presses 'p' display single page. If user presses uneven number, round to least even, i.e. '9p' would be same as '8p'. | 19:50.20 |
| Robin_Watts | The second is a new app, mupdfposter, that takes a PDF file, and makes a new PDF file from it, with the pages from the original split into smaller ones. | 19:51.00 |
| | I wrote it as a proof that we can easily read a pdf in, manipulate it and write it out. | 19:51.30 |
| | I had to add a new function pdf_new_ref to the core to make it possible. | 19:51.40 |
| | debjan: OK, that introduces certain complexities. | 19:52.09 |
| | First let me say, that the core of MuPDF is entirely capable of doing that, | 19:52.21 |
| | But the simple cross platform viewer app (which is really just a thin layer on top) doesn't support anything like that. | 19:52.56 |
| | At the moment the viewer app assumes that the window should fit the size of the page. | 19:53.42 |
| | To change that would require some reworking in the viewer app. | 19:53.58 |
| debjan | Is it because of mobile support Android? | 19:54.26 |
| Robin_Watts | I think it's fair to say that the windows/linux viewer app is not a focus of much development, and is not likely to be. | 19:54.33 |
| debjan | For PC it wouldn't be so hard, I imageine | 19:54.42 |
| Robin_Watts | No, the android app is completely separate, and much more featureful. | 19:54.45 |
| | I would imagine that it's not hard to write a PC app to do that. | 19:55.17 |
| | It's just not the way the current viewer app is setup to work. | 19:55.30 |
| debjan | Yes - SumatraPDF - Windows, zathura - Linux | 19:55.38 |
| | but zathura is a bit problematic | 19:55.52 |
| Robin_Watts | Right. So our focus is on the core, not the viewer app. | 19:55.58 |
| debjan | OK, I just wanted to post this idea | 19:56.05 |
| Robin_Watts | We have 'nicer' apps for Android and iOS. | 19:56.14 |
| | BUT... if you wanted to add such a feature to the app, and then give us the patch, we'd certainly consider it. | 19:56.36 |
| debjan | I'm just a scripter unfortunatelly | 19:57.03 |
| | OK, thanks for your time, and keep up the good work | 19:57.14 |
| | Cheers :) | 19:57.21 |
| mvrhel_laptop | ok fixed the rendering issue... | 20:55.27 |
| ray_laptop | I've found the performance issue that cust 532 came up with. If a PDF has /TR2 /Default in a ExtGState it will re-run the transfer function every time that GS is set. This (AFAICT) also applies to BG2 and UCR2 (which are not common) | 21:27.46 |
| | shouldn't be too hard to fix (in pdf_draw.ps) | 21:29.26 |
| marcosw | mvrhel_laptop: How did the fire alarm go? | 22:58.07 |
| mvrhel_laptop | marcosw: it lasted about 10 minutes | 22:58.41 |
| | then they only wanted to let people in who had badges.... | 22:58.55 |
| marcosw | I figured you were back in, I saw you running another cluster job. | 22:59.18 |
| mvrhel_laptop | yes. making some good progress | 22:59.49 |
| Robin_Watts | mvrhel_laptop: 303 seems odd in your latest bmpcmp | 23:28.15 |
| mvrhel_laptop | have not run a bmpcmp yet | 23:29.00 |
| | Robin_Watts | 23:29.07 |
| Robin_Watts | ah, ok :) | 23:29.08 |
| | (sorry, was being nosey :( ) | 23:29.19 |
| mvrhel_laptop | no worries | 23:29.28 |
| | almost down to the same segvs as the trunk with the psdcmyk 300 device | 23:30.51 |
| sibbo | hi, i'm using ghostscript to learn a lil postscript, but my "workingchain" right now looks like this: 1. ed foo.ps -- 2. gs foo.ps / quit -- 3. ed foo.ps -- 4. gs foo.ps ... and so on :( // how can i edit my ps-files with ghostscript and why is it that this x-window disapears and never comes back after i tabed to gs-shell? | 23:32.33 |
| Robin_Watts | sibbo: sorry? | 23:34.01 |
| | You edit a postscript file. Then you call gs on it. Then you quit from the gs prompt. | 23:34.34 |
| | What's happening that you don't expect ? | 23:34.44 |
| sibbo | how can i edit the file from within gs? | 23:35.32 |
| Robin_Watts | You can't 'edit your ps files with ghostscript'. Ghostscript is not an editor. It's an interpreter. | 23:35.36 |
| sibbo | :( | 23:35.43 |
| | thought it has an interactive "shell" !? | 23:35.59 |
| Robin_Watts | Yes. | 23:36.04 |
| | if you run just gs, you can type postscript commands in directly. | 23:36.16 |
| sibbo | do they get stored at the stack - or what happens to those commands? | 23:36.44 |
| Robin_Watts | they get interpreted each time you hit return. | 23:36.58 |
| sibbo | ok | 23:37.03 |
| Robin_Watts | That will (depending on the commands you type) cause things to go onto/off of the stack etc. | 23:37.20 |
| sibbo | what about that x-window? it covers the shell and when i close it it never reapears? | 23:37.49 |
| Robin_Watts | sibbo: Well, that's the output window. | 23:38.26 |
| | If you close it, then it's gone. Why not just move it out of the way? | 23:38.46 |
| sibbo | i know - but it is also opened when i invoke gs without any file | 23:38.52 |
| Robin_Watts | Or use something other than the display device. | 23:38.59 |
| sibbo | i can't | 23:39.00 |
| Robin_Watts | That's odd. I can. Maybe you are using a wacky X setup. | 23:39.26 |
| sibbo | Robin_Watts: you mean like producing png or jpegs or whatever? | 23:39.29 |
| Robin_Watts | sibbo: yes. | 23:39.36 |
| | gs -sDEVICE=png16m -o out.png input.ps | 23:40.06 |
| sibbo | how comes the output-window can't be reopened without closing gs first? | 23:40.33 |
| Robin_Watts | sibbo: It probably reopens when you do a showpage | 23:40.53 |
| mvrhel_laptop | there is def. something odd going on in the pattern code | 23:41.01 |
| sibbo | Robin_Watts: not at my wacky X ;) | 23:41.25 |
| Robin_Watts | mvrhel: is it clist patterns inside a clist device ? | 23:41.43 |
| mvrhel_laptop | yes. I am looking at that one now | 23:41.55 |
| | what fun | 23:41.57 |
| | it looks like such a simple rendered file | 23:42.11 |
| Robin_Watts | Is it something like one of the clist things isn't realising that it's a planar device ? | 23:42.41 |
| mvrhel_laptop | maybe. | 23:42.55 |
| Robin_Watts | IIRC the clist device checks to see if the underlying device is planar when it starts up and stores the results. | 23:43.20 |
| mvrhel_laptop | yes. | 23:43.26 |
| Robin_Watts | I wonder if it's worth breakpointing that to see if it ever gets told it's not a planar device... | 23:43.41 |
| | yeah. in the pattern-clist case it's coming back false. | 23:46.17 |
| mvrhel_laptop | oh where did you do a breakpoint? | 23:48.13 |
| | bmpcmp is finished | 23:48.18 |
| | overprint is broken for some reason | 23:48.52 |
| Robin_Watts | In clist_set_planar | 23:49.34 |
| mvrhel_laptop | they are kicking us out now | 23:50.08 |
| Robin_Watts | The 4th (or 5th?) call there goes into clist_dev_spec_op which returns cdev->is_planar and gets 0 back. | 23:50.13 |
| mvrhel_laptop | ah ok | 23:50.19 |
| | I will take a look at that tonight | 23:50.24 |
| Robin_Watts | mvrhel_laptop: OK. I'm off to bed in a sec anyway. Let me know if I can look into anything tomorrow. | 23:50.36 |
| mvrhel_laptop | ok thanks Robin_Watts | 23:50.43 |
| | good night | 23:50.47 |
| Robin_Watts | you too. | 23:50.53 |
| | Forward 1 day (to 2012/04/26)>>> | |
IRC Logs