| | <<<Back 1 day (to 2014/01/21) | 2014/01/22 |
| spinoli | mupdf devs (and/or close watchers): i noticed bug #694957 and the fix for it that was checked in. is there any public statement/decision on whether a new mupdf version will be cut (1.3.1, or 1.4, or whatever) soon, that would incorporate the fix? | 02:59.35 |
| tor8 | spinoli: the next release is scheduled to come out in march or april I believe | 03:00.17 |
| spinoli | i'm a gentoo user and there is not yet (afaik) an updated mupdf .ebuild in the gentoo portage tree that incorporates that fix, so i was going to create one and submit it in a bug request to bugs.gentoo.org | 03:00.30 |
| | but i want to check if i should recommend "make a snapshot based on git commit deadbeef" vs "use the new release due RSN" | 03:01.04 |
| | ah, thanks. sounds like i should do the former, then. | 03:01.11 |
| tor8 | spinoli: we try to keep the code in fairly stable shape, so deadbeef ought not to create significant problems | 03:01.32 |
| | I think we're having a pretty calm week, nothing drastic has gone in lately | 03:01.50 |
| spinoli | (i'm not positive that bug is exploitable on Linux, so i will treat it like it is) | 03:01.53 |
| | cool, thanks! | 03:02.05 |
| tor8 | though we are working actively on more security related fixes and crashes so if you could wait a few weeks that'd probably net you more fixes | 03:02.15 |
| | it all depends on how urgently you want the fixes upstream. we generally let distros do whatever they want in terms of releases. | 03:02.57 |
| | but we make our own releases twice a year, one in spring and one in autumn | 03:03.18 |
| spinoli | i noticed recent discussions in your bug tracker & irc logs about some other issues recently getting fixed, valgrind reports and whatnot | 03:04.40 |
| | i will add notes to that effect in the ticket | 03:05.30 |
| | realistically, although i have the browser tab open at b.g.o and started filling it out, it might be a week before i finish and submit it (going to create an .ebuild against whatever git commit, and test it locally, before submitting) | 03:06.41 |
| tor8 | night all. way too late for me. | 03:14.18 |
| mobjax | Hi Robin_Watts Good Morning | 07:10.13 |
| Robin_Watts | morning mobjax | 09:36.48 |
| mobjax | Hi I rebuilt the MuPDF library | 09:43.26 |
| | and I found the library is able to open one specific PDF | 09:43.41 |
| | but it is taking so much time in rendering the same, | 09:43.54 |
| | and in the mean time if I press the back button it stops abruptly | 09:44.07 |
| Robin_Watts | but your other problem is solved? | 09:44.43 |
| mobjax | this is the only problem i had | 09:44.54 |
| Robin_Watts | Ok. | 09:45.01 |
| | So go to bugs.ghostscript.com, and make an account. | 09:45.11 |
| | Then make a bug, and attach the PDF file. | 09:45.26 |
| mobjax | can I upload the PDF file there | 09:45.33 |
| Robin_Watts | slow rendering is something we should look at. | 09:45.38 |
| mobjax | and that PDF has so many pictures | 09:46.03 |
| | inside it | 09:46.11 |
| kens | CHRISL PING | 09:52.30 |
| | Oops caps | 09:52.36 |
| chrisl | kens: pong (but going out very soon) | 09:52.49 |
| kens | No rfeal quick | 09:52.54 |
| | No problem, real quick | 09:53.02 |
| | the xpsprint.dll does not exist in earlier versions of WIndows and does indeed cause the application to fail | 09:53.20 |
| chrisl | Okay, that's not surprising..... | 09:53.42 |
| kens | So we either need to distribute a dummy xpsprint.dll or have multiple different executables | 09:53.45 |
| | FOr now, can we have it built as a different target ? So henrys and michael can test it ? | 09:54.08 |
| chrisl | I can make it a command line option whether to include it or not | 09:55.01 |
| kens | It'll need some kind of #define so that xpswrite.c can optionally ocmpile in the call, command line is fine by me | 09:55.20 |
| | No rush of course | 09:55.36 |
| chrisl | I'm adding a CFLAG option, as well as the __WIN32__ anyway, so that's not a problem | 09:55.54 |
| kens | SOunds good, thanks | 09:56.03 |
| chrisl | I've also spent quite a while working out an automatic method of identifying whether we're build on a 32 or 64 bit system, so it doesn't need added to the nmake command line any more | 09:56.57 |
| kens | Oh that will be nice to have | 09:57.09 |
| | But will we still be able to spcify if we want a differnt one ? | 09:57.23 |
| | Eg I'm on a 64-bit system, but want to build and test a 32-bit executable | 09:57.45 |
| chrisl | This isn't the resulting exe, this is the current *system* - so where to fine the VS tools | 09:58.10 |
| kens | Ah, gotcha | 09:58.17 |
| chrisl | Anyway, nmake is p*ssing me off right now, so I'm going to smash a little ball around for a while....... | 09:58.40 |
| kens | Have fun, I'm about to wrestle with nmake myself for gsview..... | 09:58.57 |
| chrisl | Not riding today? | 09:59.26 |
| kens | Yes but not for another 30 minutes (leaving the house that is) | 09:59.48 |
| | Had a conference call with that customer last night, finished at 9 pm.... | 10:00.04 |
| chrisl | Oh, right. OKay, I'll be back in a few hours...... | 10:00.12 |
| kens | bye | 10:00.16 |
| mobjax | Hi Robin_Watts, I opened a bug in http://bugs.ghostscript.com/ | 10:35.08 |
| Robin_Watts | mobjax: If you have a backtrace to post on the bug, that would be appreciated too. | 10:39.26 |
| mobjax | shall I post it in the same bug | 10:42.18 |
| Robin_Watts | yes. | 10:42.26 |
| | All information about the same problem gets put on the same bug. | 10:42.38 |
| mobjax | ok | 10:43.12 |
| | I added the back trace to the post | 10:55.58 |
| Robin_Watts | That is not a backtrace from the current version. | 10:57.31 |
| | So what possible good is it? | 10:58.14 |
| mobjax | ohh is it | 10:58.15 |
| | ?? | 10:58.22 |
| | I didn't get you | 10:58.27 |
| Robin_Watts | Line 606 of PageView.java is not in addHq | 10:58.39 |
| mobjax | oh i think i posted wrong code | 10:59.05 |
| Robin_Watts | Are you going to post the correct backtrace? | 11:41.23 |
| | tor8: ping | 11:45.01 |
| | paulgardiner: http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/bates_numbering.pdf | 11:45.49 |
| | I may try adding/removing some bates numbers later using Acrobat 9 Pro. | 11:46.31 |
| paulgardiner | Saved to my specs dir ta | 11:46.39 |
| Robin_Watts | If it's just adding/removing some data, then it might be easy. If it's adding/removing some sort of annotation thing to get a visual appearance, that's harder. | 11:47.42 |
| paulgardiner | Visual appearance generation has become a lot easier since you implemented the pdf device, although the font handling still needs work | 11:49.30 |
| Robin_Watts | fonts would be key here, I fear. | 11:49.51 |
| paulgardiner | On a brighter note, I think I have a way forward with the GhostDocs resources under Android | 11:52.19 |
| Robin_Watts | excellent! | 11:52.59 |
| tor8 | Robin_Watts: pong. | 12:01.37 |
| | paulgardiner: Robin_Watts: I learned something new yesterday. http://pastebin.com/mtUZghrC what is the result? | 12:02.04 |
| | (the same thing goes for java as well) | 12:02.25 |
| paulgardiner | Surely not!!!! | 12:03.22 |
| | It's 8 otherwise you wouldn't be surprised | 12:03.46 |
| tor8 | I've never used or seen finally being used in practice | 12:04.29 |
| | so the semantics of it were a bit of a surprise. and oh my god they are odd. | 12:04.54 |
| paulgardiner | So it is 8?! | 12:04.59 |
| tor8 | it is 8. | 12:05.02 |
| | the 42 is evaluated then discarded when the finally hits the break | 12:05.26 |
| Robin_Watts | That kinda makes sense. | 12:05.54 |
| tor8 | the way the java virtual machine handles exceptions is crazy! | 12:06.06 |
| | in java, the compiler inlines the finally block at every exit point (throw, break, continue, return) that crosses the try/finally border | 12:06.53 |
| paulgardiner | kinda, but still surprises the hell out of me | 12:06.53 |
| tor8 | paulgardiner: glad I'm not the only one caught off guard :) | 12:07.08 |
| Robin_Watts | I'm not saying I'm not slightly surprised, but it's not a complete headfuck. | 12:07.34 |
| mobjax | I am not getting any crash, | 12:08.13 |
| | but the App silently exists | 12:08.20 |
| | Exits* | 12:08.26 |
| tor8 | Robin_Watts: it becomes obvious once you know what the compiler will do | 12:08.55 |
| | trying to read that behaviour out of the ecmascript spec is madness though, the way they formulate control flow in that spec is awkward at best | 12:09.28 |
| mobjax | I have 4 PDFs lined up in my folder | 12:09.30 |
| | and if i select that specific PDF | 12:09.45 |
| | it tries to render, and in mean time if I press back button | 12:09.56 |
| | I am safely landing on the list screen, | 12:10.04 |
| | but if i select any other pdf to open, | 12:10.12 |
| | the app opens it and then exits the Application | 12:10.40 |
| Robin_Watts | tor8: The first interesting thing I take from this example is that 'break' in a finally block doesn't just exit the finally block, it does a break in the enclosing block. | 12:10.58 |
| tor8 | Robin_Watts: sort of similar to duff's device, I reckon | 12:29.59 |
| Robin_Watts | tor8: 1 review on robin/master | 12:52.33 |
| tor8 | Robin_Watts: looks reasonable, though I wonder if it wouldn't be alright to just bail when the table fills up? | 13:27.32 |
| | I guess adding more ranges would be a better fallback, but we're still going to get broken results | 13:28.00 |
| Robin_Watts | tor8: In theory, the table should never fill up for a well formed cmap. | 13:28.32 |
| | possibly we could be more aggressive in checking for contradictions as we build the cmap. | 13:28.55 |
| | but then that would be slower. | 13:29.04 |
| tor8 | Robin_Watts: it might, for a mega-unicode cmap that has mappings that extend way past 64k entries. but that's a pretty unlikely scenario. | 13:29.18 |
| Robin_Watts | But we drop all entries that go past 64k. | 13:29.38 |
| tor8 | oh yeah, both on input and output. | 13:30.07 |
| Robin_Watts | but this way if a cmap is broken at the end, we still do our best to use it, and hence will give correct results for the common 'low' chars. | 13:30.24 |
| tor8 | Robin_Watts: the qsort that's in there at the top of pdf_sort_cmap should allow us to coalesce all consecutive ranges | 13:30.49 |
| Robin_Watts | My solution may not be the best possible, but it's safe at least, and doesn't introduce any new problems. | 13:30.56 |
| | yes, on a well formed map, we do well, I think. | 13:31.10 |
| tor8 | but I guess we could try smarter to combine singletons vs ranges | 13:31.10 |
| Robin_Watts | I thought we did coalesce singletons and ranges in the pass after the qsort. | 13:31.39 |
| tor8 | Robin_Watts: the alternative I guess is to just emit ranges as a series of singles when the table is full | 13:31.54 |
| | Robin_Watts: it is the very loop you've edited that does the coalescing | 13:32.15 |
| Robin_Watts | yeah. | 13:32.29 |
| tor8 | I think if we want to be strictly correct, we can map range to table by mapping each entry individually as a singleton | 13:33.01 |
| | in the error cases | 13:33.03 |
| | it'll be a pathological cmap, but binary searching would still work on it and find the right results | 13:33.25 |
| | one-to-many would be impossible though | 13:33.42 |
| | I can't remember what the abbreviatons were supposed to mean anymore (SR, R, SS, RR, etc) | 13:34.51 |
| | Single, Lookup, Range maybe? | 13:35.08 |
| Robin_Watts | i think so. | 13:35.36 |
| | I suspect that we're fine just to go with what I've got until we find a real world case where we do badly. | 13:36.16 |
| tor8 | let me read your patch once more | 13:36.34 |
| | I think if we just skip adding to the table, (and do the XX -> XX case as you have done) we should simply just work | 13:37.01 |
| | it won't merge them, but the result should still be good | 13:37.09 |
| | it's adding a one-to-many mapping that we should just drop completely when creating the original table | 13:37.43 |
| Robin_Watts | The problem is that 1) we call add_table several times, and would need to back that out in case of failure. | 13:38.07 |
| tor8 | and an original range-to-table that overflows on input | 13:38.18 |
| | that one I think we could rewrite in the fail case (I wouldn't worry about leaving garbage entries in the table once it's full) | 13:38.38 |
| Robin_Watts | and 2) that we call add_table after doing the other part. | 13:38.41 |
| tor8 | Robin_Watts: yeah, add_table and then check if we should make a range for it, that's a good catch | 13:39.06 |
| Robin_Watts | 1) requires us to be able to detect add_table failing, which is why I have a return 0 or 1 in there now. | 13:39.16 |
| | and 2), is just reversing the order. | 13:39.24 |
| | If we fail, I just don't coalesce. | 13:39.46 |
| tor8 | Robin_Watts: the sorting is all good | 13:39.57 |
| | adding a one-to-many just skips the offender | 13:40.10 |
| | which is fine | 13:40.14 |
| | range-to-table though, I think we could make correct in the else case by just emitting each table entry as a 1-wide range | 13:40.39 |
| | though as you say, it's only bad input data that will trigger the case so LGTM | 13:41.32 |
| Robin_Watts | ok, ta. | 13:41.52 |
| tor8 | though it'd be a two liner to fix :) | 13:42.15 |
| Robin_Watts | I will leave that to you, as you understand it :) | 13:42.31 |
| tor8 | btw, you can rebase and commit the two on tor/master (and review the top one) if you have a moment to spare | 13:42.51 |
| Robin_Watts | sure. | 13:43.06 |
| kens | chrisl did you say you had managed to get gsprint to build ? I can't manage it with VS 2008 :-( | 13:44.34 |
| chrisl | kens: I haven't tried it with 2008 | 13:45.17 |
| kens | Totoal nightmare :-( | 13:45.28 |
| | OK forget that, I finally managed it | 13:47.06 |
| | Had to hack gthe makefiles about to remove references to the WINdows help compiler, change the invocation of teh resource compiler, copy libraries from Program Files\... to Program FIles (x86)... but I finally have an executable | 13:47.53 |
| | And it doesn't seem to have a debug target..... | 13:48.10 |
| Robin_Watts | tor8: Isn't there a danger of a NULL deref in that last one ? | 13:49.33 |
| | if node->left = NULL, and key < node->key ? | 13:50.11 |
| tor8 | only the top node can be null | 13:50.13 |
| | all leaf NULL nodes point to sentinel | 13:50.29 |
| Robin_Watts | oh, ok. | 13:50.40 |
| | why did we do it like that? | 13:51.02 |
| tor8 | the top node is allowed to be NULL to save me having to leak the sentinel pointer to the outside | 13:51.06 |
| | api wise | 13:51.08 |
| | so that when we init the fz_tree, it can be null, but internally it always uses the sentinel | 13:51.31 |
| chrisl | kens: it built for me as you sent it with VS2008...... | 13:52.23 |
| tor8 | Robin_Watts: actually, I just spotted a piece in your last commit that is redundant. there is already a table overflow check in pdf_map_range_to_table | 13:52.31 |
| kens | chrisl, gsprint, not xpsprint :-) | 13:52.42 |
| Robin_Watts | I pushed it already. | 13:53.01 |
| tor8 | Robin_Watts: don't worry, I'm adding my emit it as a set of singles change in the same spot | 13:53.19 |
| chrisl | kens: doh, sorry. No I would have used 2003 or 2005 for gsview/gsprint when I tried it | 13:53.24 |
| kens | chrisl yes, I'm sure I would have too. THe makefile simply doesn't work as it stands with VS 2008, not least because the help compiler no longer ships. | 13:53.51 |
| | The resource compiler doesn't seem to like being invoked from a path with spaces (butits fine with just 'rc if it sin the path) | 13:54.24 |
| Robin_Watts | I've pushed your two now too. | 13:54.28 |
| kens | chrisl I wonder how on Earth Russell debugged this. There seems ot be no debug target | 13:55.25 |
| chrisl | kens: he probably hacked the flags in the makefile when required | 13:56.28 |
| kens | chrisl Ick :-( | 13:56.38 |
| | I'm wondering if I might be best just to make a new solution and wotk that way figuring out what I need as I go. THis is just naff | 13:57.09 |
| kens | fetches coffee........... | 13:57.20 |
| tor8 | Robin_Watts: improvement to cmap fix on tor/master now | 13:57.30 |
| Robin_Watts | tor8: ok. | 14:03.16 |
| | looks good to me. | 14:03.26 |
| tor8 | Robin_Watts: ta. | 14:23.36 |
| kens | Robin_Watts : can you remember how to tell the compiler that you want ANSI not 'W' functions / Eg GetProfileStringA not GetProfileStringW ? | 16:26.59 |
| mvrhel_laptop | good morning | 16:28.21 |
| kens | Morning Michael | 16:28.28 |
| tor8 | kens: suffix all functions with A. a.k.a. nuke the site from orbit -- it's the only way to be sure. | 16:29.14 |
| kens | tor8 I'd rather not do that, its the gsprint code I'm hacking on and I don;t really want to make extensive changes, especially as it uses code from gsview as well | 16:29.49 |
| | It works OK using nmake, but not when I try to create a asolution for it. So ther emust be *some* way to do this.... | 16:30.16 |
| tor8 | kens: #undef UNICODE somewhere at the top? | 16:31.54 |
| kens | Hmm, that might work | 16:32.01 |
| | weirdly there's nothign special in the nmake coimpiler flags that I cna se. | 16:32.18 |
| tor8 | kens: yeah, it's random magic which functions you end up with. at least I've never bothered enough to figure out the flags, I just explicitly use the A or W functions. | 16:32.50 |
| Robin_Watts | kens: yeah, it's something to do with having UNICODE set or not before including windows.h | 16:32.59 |
| tor8 | but if you don't want to make changes, I think the #define UNICODE trick ought to do the work | 16:33.02 |
| Robin_Watts | but I think tor8 is right. | 16:33.13 |
| kens | I'll give that a whirl, thks both of you | 16:33.17 |
| Robin_Watts | If you want an explicit version, use A or W. | 16:33.23 |
| kens | Yeah, sadly that's not the way RUssel coded it, he just uses the undecorated names, but passes explicit ansi string all over the place | 16:33.51 |
| | OK hte #undef UNICODE worked well, thanks! | 16:34.29 |
| | OOoh, seems like I have a gspritn executable, buitl under vs 2008 in a solution, I wonder if it will work.... | 16:44.19 |
| | Seems like it does, good, now I have some chance of figuring it out | 16:45.26 |
| cg433n | Can ghostscript promote all greys in a cmyk pdf to cmyk black? | 17:06.05 |
| ray_laptop | Now, this sounds interesting "Samsung 840 EVO Series 1TB 2.5" SATA III Internal Solid State Drive" -- $480 I hadn't seen a 1TB SSD before | 17:06.06 |
| | cg433n: yes | 17:06.17 |
| kens | ray_laptop : that's a reasonable price for a big SSD | 17:06.41 |
| cg433n | How? I've been searching for hours! | 17:06.50 |
| ray_laptop | kens: that' what I thought | 17:06.50 |
| Robin_Watts | That's a blinding price. | 17:07.10 |
| kens | cg433n : If its gray, and you render to CMYK then the gray will be on the K plane | 17:07.18 |
| Robin_Watts | ray_laptop: Where? | 17:07.21 |
| ray_laptop | cg433n: first, what format output do you want ? | 17:07.26 |
| kens | suspects that the 'grey' is not in fact grey | 17:07.48 |
| ray_laptop | Robin_Watts: oh, sorry. http://l.deals.ebay.com/t.d?7YGrKT9U_0ypZc=/rover.ebay.com/rover/12/0/8_0loc=http%3a%2f%2fdeals.ebay.com%2f5000944698_2Samsung_2840_2EVO_2Series_21TB_22_25_2_2SATA_2III_2Internal_2Solid_2State_2Drive_2_2MZ7TE1T0BWK&ymmmid=1445105%26sojTags%3dymmmid%3dymmmid | 17:07.52 |
| kens | ah 'today only' 44% off | 17:08.11 |
| | Nice price though | 17:08.21 |
| cg433n | ray_laptop: tiff or pdf | 17:08.26 |
| ray_laptop | this link may be better http://deals.ebay.com/5000944698_Samsung_840_EVO_Series_1TB_2_5__SATA_III_Internal_Solid_State_Drive__MZ7TE1T0BWK | 17:08.36 |
| kens | : ray_laptop identical pages for me :-) | 17:08.53 |
| | cg433n : We are almost certainly going to have to look at an example PDF file | 17:09.53 |
| ray_laptop | cg433n: to TIFF the way to do it is to give it an ICC profile that does the color mapping you want | 17:10.34 |
| cg433n | The color profile which is need to is 'U.S. Web Coated (SWOP) v2' | 17:12.24 |
| ray_laptop | cg433n: you might also be able to do what you want with -dUseFastColor and then use 100% blackgeneration and 100% undercolorremoval | 17:13.07 |
| | cg433n: if you use that profile, Ghostscript will map whatever color using that profile. If you want to change the colors, you can't use that profile | 17:14.18 |
| | but with UseFastColor=true the input colors don't use the Device*** ICC profiles. AFAIK, the result CMYK will still use the device ICC profile, however. mvrhel_laptop would be the person to check with on that | 17:15.52 |
| | (and he'll probably see this since I just mentioned him) | 17:16.07 |
| cg433n | Let me back up, and describe why I'm trying to do this: | 17:16.21 |
| ray_laptop | starting at the beginning is always best. :-) | 17:16.48 |
| cg433n | I need to prepare images for four color process printing. | 17:17.07 |
| ray_laptop | I'm going to run get coffee. bbiab | 17:17.08 |
| | change of plans. Here for a bit longer | 17:17.59 |
| mvrhel_laptop | I will listen to the description too | 17:18.12 |
| ray_laptop | mvrhel_laptop: thanks | 17:18.21 |
| | BTW, the command line method to set 100% black generation and undercolor removal is: -c "{} dup setblackgeneration setundercolorremoval" | 17:22.32 |
| cg433n | A color image is best displayed in newsprint when the Cyan, Magenta, and Yellow channels don't produce any black colors. The data for black (and gray) colors should only be found in the Black (K) channel of an image, so that ink is conserved and only Blacks and Grays are printed from the Black plate. | 17:23.41 |
| mvrhel_laptop | cg433n: so you want black preservation of source cmyk data? | 17:24.21 |
| kens | reccomends looking at an example PDF file | 17:24.51 |
| mvrhel_laptop | or do you want a source gray image to end up going to the black channel only | 17:24.59 |
| | or both | 17:25.01 |
| kens | Lets see how the input colour is actually specified | 17:25.05 |
| ray_laptop | sounds to me like ICC profiles are needed -- similar to the type of ICC profile one would use with text to use K instead of composite CMY | 17:25.39 |
| mvrhel_laptop | ray_laptop: no lcms will do black preservation when going from source CMYK to destination CMYK | 17:26.22 |
| ray_laptop | cg433n: that is definitely NOT U.S. Web Coated (SWOP) v2 | 17:26.31 |
| mvrhel_laptop | -dKPreserve | 17:27.02 |
| ray_laptop | mvrhel_laptop: right, but if the color is specified as Gray or RGB, then what. | 17:27.26 |
| mvrhel_laptop | cg433n: I would suggest you read over the GS9_Color_Management.pdf document in the docs folder | 17:27.37 |
| | ray_laptop; there is no black preservation when the source is RGB | 17:27.48 |
| ray_laptop | (it'll probably take reading it at least three times over AND multiple google searches to look up stuff that is totally obvious to Michael ;-) ) | 17:28.26 |
| mvrhel_laptop | essentially cg433n needs to describe what he wants to occur with source RGB, source Gray, and source CMYK colors | 17:28.30 |
| ray_laptop | mvrhel_laptop: right. so a sample input file is probably needed (as kens mentioned about 30 minutes ago) | 17:29.25 |
| mvrhel_laptop | right. I suspect though he wants to play with -dKPreserve and -dDeviceGrayToK | 17:29.57 |
| cg433n | I actually know very little about color profiles: My area of expertise is actually web development, I've only recently begun doing some print design. Here is a link to an example problem image: https://www.dropbox.com/s/v7ic6ub31q731l0/aussie-tan-cmyk.pdf | 17:30.29 |
| mvrhel_laptop | ok so it is a source CMYK image | 17:31.44 |
| | if you use -dDeviceGrayToK=1 then the K channel will be untouched in the color transform | 17:32.09 |
| | oops | 17:32.17 |
| | sorry | 17:32.19 |
| | use -dKPreserve=1 | 17:32.25 |
| | cg433n | 17:32.30 |
| | assuming your output device is CMYK | 17:32.45 |
| cg433n | If you separate the process plates, you will observe that the textual content of the work (and other black material) is being displayed by all four process plates. | 17:32.55 |
| mvrhel_laptop | and the colors will be as close as they can be to SWOP CMYK v2 with that constraint of K being constant | 17:33.12 |
| | or untouched I mean | 17:33.17 |
| kens | Ooops its late, goodnight all | 17:33.34 |
| Robin_Watts | morning marcosw. | 17:34.08 |
| mvrhel_laptop | cg433n. this is the source file that you want to render that you have given us right? | 17:34.11 |
| cg433n | Yes. | 17:34.24 |
| mvrhel_laptop | ok. there is no real "text" in this file | 17:34.37 |
| | it is just one big image | 17:34.45 |
| cg433n | True. I was just referring to the rasterized text. | 17:35.14 |
| mvrhel_laptop | ok yes. I see the black test has c,m,y and k | 17:36.00 |
| | s/test/text/ | 17:36.06 |
| | cg433n: so what is it that you want to do? | 17:36.32 |
| cg433n | How did you test? Was it a ghostscript command? | 17:37.00 |
| mvrhel_laptop | cg433n: s/test/text/ was me correcting my previous statement which should have been ok yes. I see the black text has c,m,y and k | 17:37.38 |
| | cg433n: but I don't know what you want to do with this file | 17:38.05 |
| cg433n | It's difficult to explain. | 17:38.10 |
| | (I'm about to try) | 17:38.25 |
| mvrhel_laptop | cg433n: I have to leave in a bit to take son to Dr.. So I fear we are going to run out of time | 17:38.39 |
| ray_laptop | cg433n: go ahead an explain. One of might be able to help | 17:39.11 |
| chrisl | Presumably wherever C=M=Y=K=x convert to C=0 M=0 Y=0 K=x | 17:39.37 |
| ray_laptop | cg433n: from what you said previously, I think you want the colors in the image that are CMY to come out as K which is what 100% black generation and 100% undercolorremoval does | 17:40.26 |
| cg433n | Basically I need to eliminate all 'rich' blacks from the work, so that all blacks and grays in the work become 'plain' blacks. | 17:40.29 |
| mvrhel_laptop | that is going to have to be done with a custom ICC profile | 17:40.49 |
| cg433n | chrisl: Nailed it. | 17:40.50 |
| mvrhel_laptop | or | 17:40.55 |
| Robin_Watts | chrisl: Urm... or C=M=Y=x, K=y => C=M=Y=0, K=y+x | 17:40.58 |
| mvrhel_laptop | you could do some coding and do your own custom color stuff | 17:41.13 |
| ray_laptop | cg433n: now if the "rich" blacks don't have exactly equal CMY you would still get a little bit on other ink | 17:41.25 |
| chrisl | Robin_Watts: I'd only want to catch "genuine" super-blacks | 17:41.32 |
| ray_laptop | chrisl: We need to understand what cg433n (not what you want ;-) ) | 17:42.17 |
| chrisl | ray_laptop: true..... | 17:42.31 |
| Robin_Watts | This strikes me as something that several people have mentioned wanting, but no one has been able to give us a clear definition. | 17:42.56 |
| | "I just want it to look better". | 17:43.03 |
| cg433n | Robin_Watts: That's just it: I'm not exactly sure about what terminology to use. | 17:43.37 |
| Robin_Watts | cg433n: Don't feel bad. I work here, and color is still largely a mystery to me. | 17:44.11 |
| cg433n | Adobe Acrobat Pro titled this functionality, "Promote Gray To CMYK Black" | 17:45.16 |
| | http://help.adobe.com/en_US/acrobat/X/pro/using/WS58a04a822e3e50102bd615109794195ff-7b94.w.html | 17:45.20 |
| Robin_Watts | cg433n: I don't think so. I think "Promote Gray to CMYK Black" is what we do when you use -dDeviceGrayToK=1 | 17:47.01 |
| mvrhel_laptop | right | 17:47.42 |
| cg433n | Could you provide me with an example gs command using the -dDeviceGrayToK=1 switch? I'd like to see if it works. | 17:48.14 |
| ray_laptop | cg433n: that seems opposite to what you mentioned before | 17:48.23 |
| mvrhel_laptop | unfortunately I have to go. will check logs later to see how all this ended | 17:49.07 |
| cg433n | mvrhel_laptop: Sometime I'd like to open a Stackoverflow thread regarding this, for the benefit of others. | 17:50.17 |
| Robin_Watts | cg433n: What gs command are you currently using ? | 17:50.47 |
| | gs -o out.tif -sDEVICE=tiff24nc -dDeviceGrayToK=1 in.pdf | 17:51.44 |
| cg433n | None :P I only discovered ghostscript about few hours ago. | 17:51.45 |
| Robin_Watts | If you're on windows, use gswin32c.exe instead of gs. | 17:52.07 |
| kens | Robin_Watts : tiff24nc seemslike a bad idea if you want CMYK output | 17:52.21 |
| cg433n | I'm on a Mac. | 17:52.25 |
| Robin_Watts | oh, urm, yes. | 17:52.30 |
| | gs -o out.tif -sDEVICE=tiff32 -dDeviceGrayToK=1 in.pdf | 17:52.45 |
| | then maybe. | 17:52.48 |
| | on a mac its gs. | 17:52.53 |
| | it's, sorry. | 17:53.12 |
| cg433n | I'm trying it... | 17:53.13 |
| kens | OK mail sent to customer and CC'ed to support, now I'm going to run away quickly...... | 17:53.52 |
| cg433n | Yikes! I'm getting an error. | 17:54.28 |
| | Unknown device: tiff32 | 17:54.28 |
| | Unrecoverable error: undefined in .uninstallpagedevice | 17:54.28 |
| | Operand stack: | 17:54.28 |
| | defaultdevice | 17:54.28 |
| ray_laptop | actualllt you need -sDEVICE=tiff32nc | 17:54.46 |
| Robin_Watts | Thanks ray_laptop | 17:54.52 |
| ray_laptop | (there is not plain 'tiff32' device, thus the error) | 17:55.13 |
| | cg433n: note that despite the name, you can get compression from tiff32nc using -sCompression=___ where ___ is "pack" or "lzw" | 17:57.10 |
| | cg433n: BTW, I recommend reading the Use.htm, and if you are using TIFF, the Devices.htm#TIFF section | 17:58.17 |
| cg433n | It doesn't seem to be working: Unrecoverable error: typecheck in .putdeviceprops | 17:58.44 |
| | My command was: gs -o out.tif -sDEVICE=tiff32nc -dDeviceGrayToK=1 aussie-tan-cmyk.pdf | 17:59.07 |
| Robin_Watts | gs -o out.tif -sDEVICE=tiff32nc -dDeviceGrayToK=true aussie-tan-cmyk.pdf | 18:03.29 |
| | true rather than 1 maybe ? | 18:03.35 |
| chrisl | It does seem to be a boolean, yes | 18:04.56 |
| | I have to say, I really don't see any way to achieve the goal with just command line parameters - *maybe* a custom profile would work..... | 18:05.58 |
| ray_laptop | in Use.htm: -dDeviceGrayToK=true/false | 18:06.11 |
| chrisl | Baring in mind, this is CMYK in, to CMYK out, there is no "color conversion" occurring | 18:06.40 |
| ray_laptop | note that with booleans (at least most of them) -dDeviceGrayToK is the same as -dDeviceGrayToK=true | 18:07.04 |
| cg433n | How might I alter the command 'gs -o out.tif -sDEVICE=tiff32nc -dDeviceGrayToK=true aussie-tan-cmyk.pdf' to ouput a pdf? | 18:08.16 |
| sags | @kens or @chrisl (for the logs) about running without xpsprint.dll: No need for 2 distinct executables. I think it's worh looking into the /DELAYLOAD linker option. With this option references to specified DLLs are not resolved at load time, these are resolved the 1st time a function from that DLL is called. Then the application init code can check if the DLL is available (maybe a simple LoadLibrary() suffices). If unavailable avoid a | 18:08.33 |
| | to functions in the DLL; from some discussion above it seems to me the application can already run without this DLL. | 18:08.33 |
| ray_laptop | chrisl: with -dUseFastColor you will get CMYK. The blackgeneration and undercolorremoval _should_ get rid of the CMY common term | 18:08.35 |
| | I have to get coffee now. bbiab | 18:08.54 |
| chrisl | ray_laptop: I thought black generation and undercolorremoveal only affected things when converting to CMYK | 18:09.28 |
| Robin_Watts | cg433n: To produce pdfoutput you'd need to use the pdfwrite device. | 18:09.30 |
| | BUT AIUI the pdfwrite device does not currently take account of color profiles (I believe this is something that kens is working on). | 18:10.02 |
| chrisl | sags: that's one for kens, I'm sure he'll the logs | 18:10.17 |
| Robin_Watts | but if it did, you'd want something like: | 18:10.41 |
| | gs -o out.pdf -sDEVICE=pdfwrite -dDeviceGrayToK=true aussie-tan-cmyk.pdf | 18:10.55 |
| cg433n | Robin_Watts: the command 'gs -o out.pdf -sDEVICE=pdfwrite -dDeviceGrayToK=true aussie-tan-cmyk.pdf' still isn't producing the cmyk separations. | 18:14.18 |
| | BTW, I'm checking separations with 'gs -sDEVICE=tiffsep -dNOPAUSE -dBATCH -dSAFER -r600x600 \ | 18:15.10 |
| | -sOutputFile=p%08d.tif out.pdf' | 18:15.11 |
| Robin_Watts | What do you mean by "still isn't producing the cmyk separations" ? | 18:18.15 |
| | if you mean "the cmyk colors are still rich black rather than plain black", then yes, that is to be expected. | 18:18.39 |
| | As I said, pdfwrite does not currently use the color profile stuff (or at least if it does it's VERY new). | 18:19.06 |
| | And if it DOES support colormanagement, then -dDeviceGrayToK=true will ensure that pictures that are specified as gray on input will become CMYK with CMY=0 on output | 18:20.09 |
| | But your file is supplying CMYK colors with C,M,Y != 0. | 18:20.33 |
| chrisl | The current pdfwrite development code uses the ICC workflow for various things, nothing in pdfwrite in a *release* does, though | 18:20.52 |
| cg433n | As I was reading the gs documentation, I'm came across this: | 18:21.56 |
| | -dDeviceGrayToK = true/false | 18:22.01 |
| | By default, Ghostscript will map DeviceGray color spaces to pure K when the output device is CMYK based. | 18:22.06 |
| Robin_Watts | ok, so it may default on. | 18:22.36 |
| | But that doesn't change what I said above. Nor does it explain your statement. | 18:22.52 |
| cg433n | I was simply stating that rich blacks were still present in the result, whether tiff or pdf. | 18:24.34 |
| | Robin_Watts: and you were right in your assesment. | 18:25.02 |
| Robin_Watts | ok. So mvrhel_laptop was right, in that the way to do this is to write your own color profile. | 18:25.43 |
| cg433n | Is there a gs command which can convert an RGB tiff, to a CMYK tiff, the ouput having no rich black? | 18:26.50 |
| Robin_Watts | Not a trivial one, no. | 18:27.07 |
| | You could possibly do it using viewlib, but I wouldn't like to bet on it. | 18:27.59 |
| cg433n | I'm reading the gs documentation on -dDeviceGrayToK = true/false | 18:28.43 |
| Robin_Watts | The moment you convert from RGB tiff to CMYK tiff you're either using a color profile, or you're throwing away all the hard work that has been done in keeping things color correct. | 18:28.50 |
| cg433n | "By default, Ghostscript will map DeviceGray color spaces to pure K when the output device is CMYK based. The gray to k.icc profile in ./profiles is used to achieve this mapping of source gray to the colorant K. The mapping of gray to K may not always be desired. In par- ticular, it may be desired to map from the gray ICC profile specified by -sDefaultGrayProfile to the output device profile. To achieve this, one should specify -dDeviceGrayToK=false." | 18:28.52 |
| Robin_Watts | cg433n: OK. What does that have to do with your use case? | 18:29.29 |
| cg433n | How then could I take advantage of the -dDeviceGrayToK functionality with any file format? | 18:29.56 |
| Robin_Watts | In your use case we have CMYK data in, so DeviceGrayToK doesn't come into play. | 18:29.59 |
| | cg433n: If your input pdf had grey images rather than CMYK ones, you'd get what you wanted. | 18:30.24 |
| ray_laptop | cg433n: do you WANT rich black, or only K with no CMY ? I'm confused. | 18:30.46 |
| cg433n | I don't want rich black. | 18:31.05 |
| | Would it make any difference if the original image were RGB? | 18:31.27 |
| ray_laptop | cg433n: so, that's what blackgeneration and undercolorremoval are for | 18:31.38 |
| cg433n | How might I make use of blackgeneration and undercolorremoval? | 18:32.03 |
| Robin_Watts | smacks head repeatedly on desk. | 18:32.04 |
| | The only way GrayToK can come into play is if you have Gray images as input. Gray images. That's images that have 1 component. RGB images have 3 components. hence RGB images are not Gray images. So RGB images won't work with GrayToK. | 18:33.13 |
| chrisl | ray_laptop: according to the PLRM blackgeneration and undercolorremoval apply during conversion from DeviceRGB to DeviceCMYK....... | 18:33.18 |
| ray_laptop | From tje PLRM: (where UCR is the undercolorremoval function and BG is the blackgeneration function) | 18:34.09 |
| | cyan = min (1.0,max (0.0, c â UCR(k))) | 18:34.10 |
| | magenta = min (1.0,max (0.0,m â UCR(k))) | 18:34.12 |
| | yellow = min (1.0,max (0.0, y â UCR(k))) | 18:34.13 |
| | black = min (1.0,max (0.0, BG(k))) | 18:34.15 |
| chrisl | ray_laptop: that section is headed: "Conversion from DeviceRGB to DeviceCMYK" | 18:35.31 |
| ray_laptop | chrisl: hmm.. OK. So an ICC profile that maps all neutral colors to K is probably the only way to get there | 18:36.36 |
| chrisl | ray_laptop: I reckon so, yes | 18:37.08 |
| | Or do some C coding..... | 18:37.22 |
| ray_laptop | chrisl: you are right, BTW. I just tried it and if the input color is CMYK the BG and UCR don't change the color :-( | 18:37.25 |
| chrisl | On that note (me being right!), I have to go ;-) | 18:37.53 |
| ray_laptop | mvrhel_laptop probably has just such an ICC profile laying around. Sounds like what someone would want to use as the Text profile | 18:38.25 |
| Robin_Watts | The worry with such a profile used globally is that you might find you get odd results with images. | 18:39.20 |
| | I might have an image that looks nice and glossy, until suddenly certain areas of it 'drop out' to looking flat. | 18:39.53 |
| ray_laptop | But that's just what cg433n wants (I think). | 18:40.51 |
| Robin_Watts | ray_laptop: It's what he's asking for, yes. | 18:41.11 |
| | But he may not be aware of the consequences. | 18:41.23 |
| ray_laptop | Robin_Watts: it totally depends on the output device, but I agree that is quite visible on laser printers | 18:41.41 |
| Robin_Watts | Consider if I have 2 pixels in an image next to one another. One is a 'rich grey'. One is just slightly different from that rich grey, but is not longer grey. | 18:42.06 |
| | When output currently they look more or less the same. | 18:42.18 |
| | when output with the hypothetical 'map all rich greys to real greys' profile, they will be noticably different. | 18:42.59 |
| cg433n | The purpose of such a procedure is to prepare image files for four color process newsprint, color quality being an absolute minimum. | 18:43.08 |
| Robin_Watts | I suspect it will make photos unusably poor. | 18:43.49 |
| | You're probably much better off avoiding rich CMYKs getting into the pipeline in the first place. | 18:44.11 |
| | garbage in/garbage out etc. | 18:44.21 |
| cg433n | Here's an example of the effect that I'm trying to achieve: | 18:45.34 |
| Robin_Watts | I understand what you are trying to do. | 18:45.55 |
| cg433n | I would like to change an image like this: http://en.wikipedia.org/wiki/Cmyk | 18:46.04 |
| | http://en.wikipedia.org/wiki/File:Barns_grand_tetons.jpg | 18:46.15 |
| | to this: http://en.wikipedia.org/wiki/File:CMYK_separation_â_maximum_black.jpg | 18:46.25 |
| Robin_Watts | Ah, well, that's NOT what you have been asking for. | 18:47.01 |
| | That is not mapping C=M=Y=K=x to C=M=Y=0 K=x and leaving all other colors alone. | 18:47.33 |
| | That is mapping C=c M=m Y=y K =k to C=c-x, M=m-x. Y=y-x, K=k+x where x = min(c,m,y) | 18:48.23 |
| | That has no discontinuities in the function. | 18:48.50 |
| | And again, that's something that could be done with an icc profile. | 18:49.17 |
| cg433n | *Sigh* Hence my disclaimer as an absolute beginner in these matters. | 18:49.35 |
| | I suppose this discussion has landed far outside the purpose of this channel, but can anybody recommend resources/tools for further exploration? | 18:54.12 |
| Robin_Watts | I suspect you need to hang around for mvrhel to return. He's our color expert. | 18:54.47 |
| | he may know of a "maximum black" profile you can use. | 18:55.01 |
| | or tools to create one. | 18:55.13 |
| cg433n | I'll stand by. Do you have an ETA? | 18:57.23 |
| Robin_Watts | Within the next couple of hours I would imagine. | 18:58.22 |
| ray_laptop | cg433n: he said he had to take his son to the doctor. That could be a few hours | 18:58.35 |
| Robin_Watts | He's west coast america, so should be here for most of the working day after running that errand. | 18:59.02 |
| ray_laptop | in the meantime, I'll search around my collection of random stuff (and the web) and see if I can scrounge one up. | 18:59.19 |
| | but now I have to run an errand. bbiaw | 18:59.38 |
| cg433n | I'm in Arizona. Thank you all for your help! | 19:00.38 |
| Robin_Watts | http://www.damiensymonds.com.au/art_newsprint.html might be useful? | 19:01.03 |
| cg433n | Thanks! The linked article describes the process from within Photoshop. I'm trying to achieve the same result on the command line. | 19:05.05 |
| Robin_Watts | The article describes how to make photoshop generate a profile. | 19:05.47 |
| | that same profile is what you need to use with gs. | 19:05.58 |
| henrys | marcosw: do you have a binary for looking smart office files - are the visual problems in your report to do with pdf generation or are they broken in display also? | 20:30.20 |
| tkamppeter | henrys, hi | 20:42.04 |
| henrys | tkamppeter: hello | 20:42.27 |
| tkamppeter | henrys, it is about bug 693715, an issue in the PCL output. There is a patch and it is successfully tested. Shouldn't we apply it? | 20:43.35 |
| henrys | tkamppeter: yes I'll apply that one. We never did hear back from the OP | 20:46.09 |
| tkamppeter | henrys, yes and another person tried and tested it, so it is actually tested. | 20:46.52 |
| henrys | tkamppeter: you can go ahead and commit it if you like. | 20:47.35 |
| | tkamppeter: either way let me know | 20:48.45 |
| tkamppeter | henrys, have commited it, so the bug is fixed now. | 21:10.04 |
| henrys | tkamppeter: great | 21:10.28 |
| mvrhel_laptop | I am back | 21:19.35 |
| | hello cg433n: so if you want some special back handling (e.g. maximum black) then you will need to find (or create) an ICC profile to give you that effect | 21:28.00 |
| | there is software for purchase from various vendors for manipulating profiles | 21:28.41 |
| | unfortunately, we don't provide this sort of thing | 21:28.56 |
| | once you find or create it you would run ghostscript with -sOutputICCProfile="My_Profile.icc" | 21:29.45 |
| | oops | 21:29.51 |
| | that was weird | 21:29.56 |
| | with -sOutputICCProfile="My_Profile.icc" | 21:30.21 |
| | where that is the name of the output profile that gives you the type of rendering you are looking for (e.g. maximum black) | 21:30.47 |
| | not sure what kind of press/printer you are going out to but you may need to create the profile based upon that. unless you are just shooting for SWOP | 21:32.04 |
| | thats all I have for you | 21:37.20 |
| | bbiab | 22:09.58 |
| ray_laptop | poor "yards" For whatever reason it was 7 times slower than leagues on my last regression run | 23:41.47 |
| | Forward 1 day (to 2014/01/23)>>> | |
IRC Logs
