| | <<<Back 1 day (to 2014/05/21) | 2014/05/22 |
| marcosw | pedro_pc is up early and henrys is up late... | 06:25.33 |
| sebras_ | https://code.google.com/p/pdfium/ | 07:01.17 |
| | googles pdf reader was open sourced today. | 07:01.42 |
| | the one for chrome. | 07:01.57 |
| | oh. this was originally developed by foxit. | 07:04.09 |
| chrisl | reboots | 08:10.16 |
| sebras | Robin_Watts: do you think pdfium has something interesting in it? | 08:49.05 |
| Robin_Watts | sebras: I haven't really looked. | 08:52.02 |
| tor8 | Robin_Watts: one-line bugfix on tor/master for the optimized CMap bug I found yesterday | 10:58.40 |
| kubilayrd | hi all | 11:02.05 |
| | I am using GS to convert PDF file to PNG image(s) | 11:02.15 |
| | however, the color tones of converted image differ from the original file | 11:02.33 |
| | I was wondering if we have any optional parameter for colors | 11:02.47 |
| tor8 | how can you tell, if the PDF is the original file? | 11:03.09 |
| kubilayrd | what do you mean? | 11:03.28 |
| tor8 | which colors are you comparing | 11:03.33 |
| kubilayrd | some text's color on the pdf file and converted image | 11:03.57 |
| tor8 | and how do you know which color is in the PDF except by converting? | 11:04.15 |
| | well, more accurately asked: how do you know which color is in the PDF? | 11:05.01 |
| kubilayrd | I open the pdf file and see? | 11:05.16 |
| chrisl | Open it in what? | 11:05.29 |
| kubilayrd | I preview colors with DigitalColor Meter tool in OS X | 11:05.44 |
| | and see there are differences in values | 11:05.51 |
| | open it in preview app | 11:06.00 |
| chrisl | Could be Ghostscript is right, and preview is wrong..... | 11:06.39 |
| kubilayrd | Allright, I think I was mistaken | 11:06.39 |
| | I see | 11:06.51 |
| | how can I convert these PNG files to JPG with GS? | 11:07.06 |
| tor8 | there's a ton of things that could be different. Preview app might be using your system's display colorspace conversion, where GS doesn't. | 11:07.08 |
| kubilayrd | Or can I? | 11:07.09 |
| | I am using mogrify at the moment and it messes up the colors | 11:07.23 |
| chrisl | No, why not just have GS output jpeg? | 11:07.30 |
| kubilayrd | I think I had issues with the quality in text | 11:08.05 |
| | hold on a second, I will convert to JPG and try to remember what the issue was | 11:08.17 |
| tor8 | jpeg is always going to have text quality problems | 11:08.18 |
| kubilayrd | that's why I firstly convert to PNG | 11:08.31 |
| | then convert to JPEG so the text doesn't get corrupted that much | 11:08.43 |
| | can mudraw do this conversion? | 11:09.01 |
| chrisl | That's.... odd | 11:09.03 |
| kubilayrd | PNG to JPEG I mean | 11:09.05 |
| tor8 | kubilayrd: try going via PPM instead of PNG (since mogrify might be doing weird stuff to PNG colorspaces) and see if that makes a difference | 11:09.20 |
| kubilayrd | Allright, trying now | 11:09.35 |
| | current command is: | 11:09.56 |
| tor8 | kubilayrd: mudraw can do it, but gs has better colorspace handling | 11:10.03 |
| kubilayrd | gs -dNOPAUSE -sDEVICE=pngalpha -dUseCropBox -sOutputFile=target_%d.png -r190 source.pdf | 11:10.09 |
| | What should I change for PPM? | 11:10.18 |
| tor8 | try changing pngalpha to ppmraw | 11:10.26 |
| | and %d.png to %d.ppm | 11:10.37 |
| kubilayrd | OK, thanks | 11:10.41 |
| tor8 | my guess though is that Preview is applying colorspace correction for your display, which will make the color values differ from the uncorrected values output by gs | 11:11.26 |
| chrisl | Can't think why converting to something else then to JPEG would improve text quality...... | 11:11.35 |
| tor8 | chrisl: you have better control over the -q value in the conversion | 11:12.05 |
| chrisl | You can set it in gs too | 11:12.22 |
| tor8 | right. | 11:12.41 |
| chrisl | -dJPEGQ=N (integer from 0 to 100, default 75) | 11:12.44 |
| tor8 | that default is pretty low :) | 11:12.56 |
| kubilayrd | PPM is quite.. messy | 11:13.10 |
| | and the size is 10 times larger | 11:13.16 |
| chrisl | It's uncompressed | 11:13.23 |
| kubilayrd | I am now trying dJPEGQ option now with 100 | 11:13.37 |
| tor8 | kubilayrd: PPM is uncompressed. if you gzip it, it should be comparable in size to png. | 11:13.39 |
| kubilayrd | but the quality is not good as PNG | 11:13.58 |
| chrisl | No, it's lossy compression, JPEG will never be as good an PNG (which is lossless) | 11:14.21 |
| tor8 | PPM should be identical to PNG, but I expect you mean JPEG is not as good as PNG? | 11:14.43 |
| kubilayrd | no, PPM is not good as PNG, the text borders are strong way too crispy | 11:15.19 |
| chrisl | -dTextAlphaBits=2 then | 11:16.09 |
| kubilayrd | what's the max value for this? | 11:17.23 |
| chrisl | 4 | 11:17.29 |
| kubilayrd | 2 got it better, just not enough | 11:17.31 |
| | OK, trying | 11:17.36 |
| | better than before, I need to check out on tablet because the images will be used in a mobile app | 11:19.47 |
| | OK, the last command is: | 11:19.51 |
| | gs -dNOPAUSE -sDEVICE=jpeg -dJPEGQ=100 -dTextAlphaBits=4 -dUseCropBox -sOutputFile=out_%d.jpg -r190 in.pdf -c quit | 11:19.53 |
| | any more suggestions on this? | 11:19.58 |
| | for crispiness or JPG quality? | 11:20.08 |
| chrisl | Well, you can probably drop the -dJPEGQ=100 since what you apparently wanted was "fuzzier" text, not "better quality" text..... | 11:20.49 |
| kubilayrd | page are from a magazine, both contains text and images... | 11:21.21 |
| chrisl | Images were probably JPEG encoded already | 11:21.40 |
| tor8 | -dJPEGQ=90 is what I tend to use as a compromise between small size and compression artefacts | 11:21.45 |
| chrisl | You can simplify to: -dNOPAUSE -dBATCH -sDEVICE=jpeg -dTextAlphaBits=4 -dUseCropBox -sOutputFile=out_%d.jpg -r190 in.pdf | 11:21.57 |
| kubilayrd | what does -dBATCH stand for? | 11:22.16 |
| tor8 | -sDEVICE=jpeg -dTextAlphaBits=4 -dUseCropBox -r190 -o out_%d.jpg | 11:22.25 |
| chrisl | It runs gs in batch mode instead of interactive | 11:22.33 |
| tor8 | the NOPAUSE and BATCH and OutputFile are all implicit with the -o option (IIRC) | 11:22.44 |
| chrisl | True, yes | 11:22.54 |
| kubilayrd | OK, trying the commands now | 11:23.09 |
| chrisl | You might also want -dGraphicsAlphaBits=4 too | 11:23.14 |
| kubilayrd | Okay | 11:23.45 |
| chrisl | So lineart gets fuzzy to match your text | 11:24.05 |
| kubilayrd | executing now, 68 pages | 11:25.32 |
| Robin_Watts | Morning mace. | 11:43.08 |
| kubilayrd | thank you guys, it saved my from 2 more steps and quality/size satisfying | 11:43.24 |
| Robin_Watts | tor8: 1 line fix looks plausible to me. | 11:44.03 |
| kubilayrd | I have to convert these images to smaller width version as well | 11:46.26 |
| | Do you recommend conversion from the source with different -r valur | 11:46.37 |
| | or using mudraw -w option? | 11:46.45 |
| sebras | if the pages in kubilayrd's PDF are full-page images then it might be better to extract those than to resample the drawn pages..? | 11:51.04 |
| | I'm not sure what the source is, this is just an idea. | 11:51.20 |
| kubilayrd | sebras: No, they are text and image combined, magazine papers. | 11:54.17 |
| sebras | kubilayrd: ok. nermind me then. :) | 11:54.35 |
| | nevermind. | 11:54.38 |
| tor8 | Robin_Watts: thanks. there's one more commit for review now too. | 12:09.49 |
| Robin_Watts | lgtm | 12:18.04 |
| | I think the 1.4 slowdown is down to me changing flate to work 1 byte at a time. | 12:18.40 |
| tor8 | Robin_Watts: ohhh, you did? | 12:18.53 |
| Robin_Watts | I need to ponder that a bit. Putting it back to work in larger blocks will bugger inline image handling. | 12:19.13 |
| tor8 | Robin_Watts: you could write your own flate code, that is designed to work a byte at a time :) | 12:19.36 |
| | does that only affect flate, or do all filters work a byte at a time now? | 12:19.51 |
| Robin_Watts | It's only flate. | 12:20.09 |
| tor8 | right. because of the zlib api? | 12:20.19 |
| Robin_Watts | Essentially, I only want it to decode as much as it needs, not as much as it can. | 12:20.45 |
| | It may be that there is something I can do to ameliorate it. I need to get some time to think on it. | 12:21.19 |
| tor8 | even if you hand a big buffer to zlib, you can tell how much it didn't consume at the end of the deflate call | 12:24.26 |
| Robin_Watts | but I can't know... something that I needed to know. | 12:25.13 |
| jhabjan | hi, is there a way to tell ghostscript to translate ligatures to normal characters? | 12:54.45 |
| kens2 | No | 12:54.56 |
| | THere is no way to be certain a glyph is in fact a ligature | 12:55.45 |
| jhabjan | ah, ok, got it, thanks | 12:56.20 |
| tor8 | kens2: in theory, it should be possible to find ligatures by looking at the ToUnicode CMap if there are any 1-to-many mappings | 13:12.00 |
| | not very reliable in practice though | 13:12.10 |
| kens2 | and no use in PostScript at all..... | 13:12.34 |
| henrys | pedro_pc, paulgardiner_lap looks like we got what we needed, I had requested a meeting with Good and I can set that up but I don't know if we need one now, let me know if you want one. | 13:27.40 |
| paulgardiner_lap | possibly not. | 13:29.39 |
| | Probably best to wait at least until we run into the next pit fall | 13:30.14 |
| henrys | paulgardiner_lap: the threat of a meeting usually is enough ;-) | 13:31.14 |
| paulgardiner_lap | With the info they gave us, I've been able to send docs to their app for saving or emailing, so it looks like the updates for the sake of the newer SDK have worked. | 13:31.38 |
| henrys | paulgardiner_lap: is there anything with Good integration that would hinder normal SOT performance? | 13:32.21 |
| paulgardiner_lap | henrys: you mean render speed, UI liveness, that sort of thing? | 13:32.54 |
| henrys | paulgardiner_lap: yes | 13:33.10 |
| paulgardiner_lap | Hmmm. I was about to say no, but there is a mysql database that we keep in the secure area, which implies access to it is via the GOOD GDFileSystem. | 13:34.25 |
| henrys | paulgardiner_lap: a large potential client complained of performance problems so it is something for us to test once we have something. I'll add it to the agenda so it doesn't get dropped | 13:35.55 |
| | client of Good that is | 13:36.06 |
| | paulgardiner_lap: but we don't really know when SOT last worked with Good, do we? | 13:36.59 |
| paulgardiner_lap | Okay. Did they have knowledge of both versions, or were they just saying the one version they tried was slow? | 13:37.10 |
| henrys | Robin_Watts: is there something I can do to help with testing, I can assign others or can do some of it myself. Let me know. | 13:37.56 |
| paulgardiner_lap | henrys: we have a record of the last release, with date, source version etc. | 13:38.09 |
| tor8 | Robin_Watts: one more tiny fix on tor/master | 13:39.59 |
| | Robin_Watts: if you find my pinging you for every tiny fix annoying, maybe I should just go ahead and close bugs before the fixes land on golden master. | 13:40.41 |
| Robin_Watts | tor8: no problem. | 13:40.51 |
| henrys | paulgardiner_lap: when was that? I'll send you the email if you want. I told them we aren't investigating until we have a real working Good integration. | 13:40.53 |
| | ugh another performance regression. | 13:41.27 |
| Robin_Watts | tor8: lgtm. | 13:41.35 |
| | tor8: Should we be considering other unicode whitespace chars too ? | 13:42.04 |
| paulgardiner_lap | henrys: looks to be August 2013 | 13:42.49 |
| tor8 | Robin_Watts: possibly, we could use the JS list of whitespace chars but I doubt they're very common | 13:43.26 |
| paulgardiner_lap | henrys: yeah, would be interesting to see the email | 13:43.29 |
| | in some strange sense of the word "interesting"! | 13:43.44 |
| henrys | paulgardiner_lap: yes I'm afraid it did not make my interesting list ;-) | 13:45.13 |
| paulgardiner_lap | just to test my stalk match alarm: paul | 13:53.36 |
| | just to test my stalk match alarm: paul | 13:54.05 |
| | fail | 13:54.09 |
| Robin_Watts | apaulling ? | 13:54.14 |
| paulgardiner_lap | Only matches whole words :-) | 13:54.28 |
| chrisl | paul: it might have to be someone else? | 13:54.37 |
| paulgardiner_lap | 'tis broken. | 13:55.23 |
| chrisl | What client are you using? | 13:55.56 |
| paulgardiner_lap | chatzilla. I thought I just copied the config from a working client on my desktop to this one on my laptop | 13:57.31 |
| | Maybe I need to set "aggressive notification" | 13:57.45 |
| Robin_Watts | Have you set the volume for chatzilla to 0 or something in the system mixer? | 13:58.25 |
| paulgardiner_lap | Ah spelling mistake | 13:58.26 |
| Robin_Watts | pual! | 13:58.34 |
| paulgardiner_lap | That's it | 13:58.40 |
| | just to test my stalk match alarm: paul | 13:59.08 |
| | Can you try again? | 13:59.25 |
| Robin_Watts | paul | 13:59.51 |
| paulgardiner_lap | pah! | 13:59.58 |
| pedro_pc | henrys,paulgardiner_lap: we'll have to go hrough our internal test before we go to Veracode so we should probably factor in soem performance test as part of that process. I'm not sure just how much slower it would be - should be roughly the decryption cost for individual files (unless of course the Good File() instantiation is slow - we do that on each access I think | 13:59.59 |
| rayjj | morning, all | 14:23.55 |
| kens2 | Hi ray | 14:24.26 |
| rayjj | kens2: I mentioned it in the logs yesterday after opening the transparency pdfwrite bug, that if you don't get to it, I'll look into it after the other customer issues on my plate. | 14:24.46 |
| kens2 | I read the logs ray, I'm currently looking at your previous report | 14:25.14 |
| rayjj | kens2: but I'll check with you first to see if you've started looking at it. It is NOT a customer issue | 14:25.21 |
| Robin_Watts | rayjj: Did you see tkamppeters question yesterday? | 14:25.42 |
| rayjj | Robin_Watts: umm... no. Someone mentioned something abotu byte ordering of 16bpc color -- that one ? | 14:26.32 |
| kens2 | Yes thaAT ONE | 14:26.39 |
| rayjj | looks at logs ... | 14:27.00 |
| kens2 | ray I did very briefly look at the file today, and the text is present, so its omething weirdly tansparency/form related | 14:27.02 |
| rayjj | kens2: right. I knew the text was there because gs prior to my patch shows it (but Adobe and new gs don't) | 14:28.06 |
| kens2 | Ah, well like I said, somethgin weird with transparency and forms | 14:28.34 |
| | reduce the file and hte problem goes away | 14:28.42 |
| rayjj | that's why I thought I wasn't able to reproduce the issue because at first I was looking at the pdfwrite output with old gs | 14:28.48 |
| kens2 | I'm currently looking at your last report though | 14:29.06 |
| tor8 | Robin_Watts: I wonder if 695233 might be related to the stack overflow bug with fz_vfprintf | 14:29.52 |
| Robin_Watts | tor8: could be. | 14:31.04 |
| rayjj | OK, for the 16 bpc issue, gs writes whatever color is returned from the device's 'encode_color' proc. The bits in the color index can be totally scrambled. | 14:32.20 |
| tor8 | given the presence of two or three stack overflow/overrun bugs we've fixed since 1.4 it might make sense to do an early 1.5 release | 14:32.27 |
| rayjj | so I have to look at gdevcups encode color (yuck) | 14:32.50 |
| Robin_Watts | If we're going to do that, let's try and get to fix the slowdown too first. | 14:33.03 |
| kens2 | ray I don't think you need to look at cups, just do you know what hte byte ordering is for 16 bpc rasters | 14:33.58 |
| tor8 | Robin_Watts: yeah. let's not do the release before the staff meeting. | 14:34.04 |
| Robin_Watts | rayjj: Urm... the question was, (if I'm remembering correctly), when he does a getbits for 16 bits per component, does he get a pointer to big or little endian data? | 14:34.33 |
| rayjj | kens2: that's what I mean -- the byte ordering is whatever is in the color_index | 14:34.47 |
| Robin_Watts | or "native". | 14:34.48 |
| kens2 | doesn't understand, but hey.... | 14:35.17 |
| Robin_Watts | either. | 14:35.25 |
| | the ordering in the color index is "what order do components get packed into a color_index" | 14:35.48 |
| rayjj | the data returned by get_bits is from the raster buffer, with the color_index values for each pixel packed with the first pixel first. | 14:35.56 |
| | Robin_Watts: thus the need to look at how cups loads the EncodeLUT for 16 bpc color | 14:36.23 |
| Robin_Watts | The ordering of the 16 bits per *component* data in the actual memory is a different question entirely. | 14:36.26 |
| | rayjj: So if I give you a color index that is RRRRGGGGBBBB | 14:36.53 |
| | (assuming a 64bit color index) | 14:37.10 |
| | that has to get stored into memory. | 14:37.19 |
| rayjj | that's only 48 bits | 14:37.25 |
| Robin_Watts | 48 bits stored within a 64bit color index, yes... | 14:37.38 |
| | (my point is it wouldn't fit into a 32bit color index :) ) | 14:37.55 |
| rayjj | we pack the 'depth' number of bytes | 14:38.21 |
| | well, depth/8 | 14:38.31 |
| Robin_Watts | So suppose I give you a color index of 0x112233445566 | 14:39.13 |
| rayjj | and the packing is the highest bits of the color index (that we keep) in the first byte of the buffer | 14:39.20 |
| Robin_Watts | Right. So big endian. That was the question. | 14:39.41 |
| | so writing 0x112233445566 into char * raster, raster[0] would be 0x11, raster[1] would be 0x22, etc? | 14:40.36 |
| rayjj | so if a 16bpc gray color_index for 50% returns 0x00008000 color index, the buffer will contain 0x80, 0x00 | 14:40.37 |
| Robin_Watts | So big endian. | 14:41.41 |
| rayjj | Robin_Watts: if the 16bpc color index is 0x00112233445566, then the bytes in the buffer will be: 0x11, 0x22, 0x33, 0x44, 0x55, ... yes | 14:41.57 |
| Robin_Watts | tkamppeter: Does that answer your question? | 14:42.20 |
| rayjj | a device that has an encode color that is not big endian can change that. GS doesn't care what's in the bits. In your example, the 16bpc RGB could have been R=0x4411, G=5522, B=0x6633 | 14:43.50 |
| Robin_Watts | rayjj: Color indexes don't have endian issues. | 14:46.52 |
| rayjj | in fact, look at lines 4178-4815 in cups/gdevcups.c and you will see that when setting up the EncodeLUT that is used, it uses ARCH_IS_BUG_ENDIAN | 14:47.10 |
| Robin_Watts | because they are always 'native' objects. | 14:47.16 |
| rayjj | Robin_Watts: not sure what you mean by 'native' objects. color_index is opaque to the memory device. | 14:48.17 |
| | one doesn't even have to have the same number of bits per component | 14:48.42 |
| Robin_Watts | rayjj: I mean that a color_index is (as far as gs is concerned) a single native value that gets passed around. | 14:49.55 |
| | Values in registers aren't big or little endian. | 14:50.43 |
| | Only values in memory have endian issues. | 14:50.57 |
| rayjj | Robin_Watts: OK. Right. and the memory devices pack 'depth' bits into the bytes of the buffer with the most significant bits in the highest bits of the first pixel | 14:51.07 |
| Robin_Watts | Right, so the memory devices are big endian by convention. | 14:51.37 |
| rayjj | yes | 14:51.44 |
| Robin_Watts | which is what till was asking, AIUI. | 14:51.49 |
| rayjj | that's why I had to look at the encode color (or the filling of EncodeLUT) to see how it set up the values. It calculates an integer value, but then swaps bytes #if !ARCH_IS_BIG_ENDIAN | 14:53.34 |
| | it wouldn't have to do that if it wanted native endian component values out of the buffer from get_bits | 14:55.01 |
| Robin_Watts | Urm... surely it *must* do that if it wants native endian components out? | 14:55.58 |
| rayjj | which might be the case for a 12 or 16 bit device that was going to do more 'munging' of the data and didn't want to have to repack the componets according to the endian-ness | 14:56.08 |
| Robin_Watts | If it passes in a vanilla gx_color_index, then it will get big endian out, always, regardless of platform. | 14:56.53 |
| rayjj | Robin_Watts: it will get the bytes in the buffer with the highest bits of the color index first | 14:57.37 |
| Robin_Watts | If it wants to get native endian out, then on little endian targets it must shuffle the gx_color_index styff. | 14:57.42 |
| | Hence it doing extra work on #if !ARCH_IS_BIG_ENDIAN makes sense to me. | 14:58.25 |
| rayjj | Robin_Watts: I think we are in agreement | 14:58.44 |
| | w.r.t. to the cups device. | 14:58.57 |
| Robin_Watts | yes. I was just confused by "it wouldn't have to do that if it wanted native endian component values out of the buffer from get_bits" | 14:59.21 |
| | as the reason it does it is because it *wants* native endian component values out. | 14:59.43 |
| rayjj | Robin_Watts: sorry for the confusion. I hope tkamppeter got the info he needs. | 15:00.33 |
| kens2 | night all | 16:15.28 |
| Robin_Watts | tor8: Have you tested any windows builds recently? | 16:21.41 |
| tkamppeter | rayjj, Robin_Watts, I am looking through your byte order discussion currently and try to find out what is going on ... | 16:33.08 |
| Robin_Watts | tkamppeter: short answer: ghostscript writes the bytes from a gx_color_index into the raster buffers in big endian format. | 16:56.16 |
| | So when you do a get_bits you'll get a pointer to a buffer with those bytes stored in big endian form. | 16:56.44 |
| tor5 | Robin_Watts: no. are they broken? | 16:56.56 |
| Robin_Watts | BUT... cups does some internal wriggling to permute the bytes in the little endian case, so you should probably always get native endian out. | 16:57.20 |
| | tor5: yes. I have a fix here. Just some solution problems. | 16:57.30 |
| | I may also have a fix for the slowdown. | 16:57.41 |
| | I'll get them up for review later (or tomorrow) | 16:57.57 |
| tor5 | ok. | 16:58.02 |
| chrisl | tor5: how are you getting a "too many hints" error from Freetype if you disable all hinting? | 17:12.14 |
| rayjj | tkamppeter: see the EncodeLUT setup in cups/gdevcups.c circa 4178 | 17:12.40 |
| tor5 | chrisl: good question, but I guess it's a general freetype parser problem | 17:26.48 |
| | chrisl: but sometimes we do enable hinting, if the font starts with the dynalab font prefixes... | 17:27.23 |
| chrisl | tor5: IIRC, that error should only occur if freetype actually tries to execute the hints. I think in gs, we retry with the "tricky" flag disabled when that happens | 17:28.24 |
| tor5 | hmm, I guess I should try that too | 17:29.24 |
| chrisl | tor5: the case for which I introduced that change it was the notdef glyph that caused the error - how a notdef can have anything more than trivial hints is beyond me!! | 17:31.57 |
| | henrys: OpenJPEG 2.1.0 update done.... | 17:35.52 |
| henrys | chrisl: yes just reading the commit - awesome | 17:36.10 |
| | chrisl: any word from shelly? | 17:36.33 |
| chrisl | I haven't pinged him since I had dinner with him last week | 17:36.57 |
| | As I said, he's a bit snowed under with "real" work | 17:37.23 |
| | henrys: I've sent Shelly a mail, and I'll try to get to talk to him in the next few days, and devise a plan of action....... | 17:45.16 |
| henrys | great chrisl it certainly isn't critical but it would be nice to get it done | 17:46.12 |
| chrisl | henrys: well, honestly it would have been done quite some time ago with a little more cooperation from the OpenJPEG folks..... or even no cooperation at all - at least then, we'd have a clear conscience in just doing a fork..... | 17:47.30 |
| | Right, that's me for the day - bye...... | 17:57.08 |
| Adam__ | Hi! I'm converting with GhostScript CMYK PDF to CMYK TIFF with no colour conversion and i would like to saveTIFF without any ICC profile attached. Is it possibe? How to do that? | 19:12.36 |
| henrys | Adam__: so you are using -dUseFastColor and there is a profile in the tiff output? | 19:29.02 |
| Adam__ | I didn't found that switch, just a second i will test it. | 19:29.51 |
| henrys | -dUseFastColor=true | 19:30.31 |
| Adam__ | It does't work. Profile 'Artiflex CMYK SWOP' is still embedded. | 19:37.54 |
| | But colours seems to be untouched. | 19:38.29 |
| | My command line parameters are: | 19:48.45 |
| | -dBATCH -dNOPAUSE -dSAFER -sDEVICE=tiff32nc -r100 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -dDOINTERPOLATE -dUseFastColor=true -sOutputFile=test.tif test.pdf | 19:48.48 |
| | What can be wrong? | 19:48.56 |
| henrys | Adam__: unfortunately the color expert is out of town. It does seem odd to me a profile would be embedded would you report a bug at bugs.ghostscript.com? | 19:51.30 |
| Adam__ | I will look around internet to see what people say. If i no find solution i will report a bug. Thank you for help Henry. Bye! | 19:53.33 |
| tor8 | chrisl_away: (for the logs) the hints error in that file is because the glyph header has number of instructions > max instructions in the maxp table | 20:20.26 |
| mvrhel_laptop | Robin_Watts: are you there? | 22:05.45 |
| henrys | mvrhel_laptop: howdy, where are you? | 22:14.16 |
| mvrhel_laptop | henrys: in korea | 22:31.57 |
| | heading to breakfast now | 22:32.01 |
| Robin_Watts | mvrhel_laptop: -pdfexport file://localhost/out.pdf ../../MyTests/prop.pdf out.txt pdf | 22:49.54 |
| | mvrhel_laptop: Skype died on me :( | 22:50.03 |
| mvrhel_laptop | thanks Rob | 23:02.12 |
| | Robin_Watts: | 23:02.16 |
| Robin_Watts | np. | 23:04.27 |
| | Why are you playing with pdf export ? | 23:04.39 |
| | Forward 1 day (to 2014/05/23)>>> | |
IRC Logs