| | <<<Back 1 day (to 2013/09/18) | 2013/09/19 |
| arya009 | hi | 08:28.49 |
| ghostbot | niihau | 08:28.49 |
| Robin_Watts | arya009: If you have a question, ask it, don't wait for a reply first :) | 08:53.12 |
| arya009 | I need to convert an image file to pdf. It is a JPEG file, it gets converted fine but it is displayed at bottom of hte page | 08:56.54 |
| | i m using following command | 08:57.01 |
| | gswin32c -sDEVICE=pdfwrite -r300 -o MyFile-%d.pdf -dUseTrimBox C:/gs/gs9.10/lib/viewjpeg.ps -c (C:/Docs/grid.jpg) viewJPEG quit | 08:57.02 |
| kens | UseTrimBox will have no effect as it uses the TrimBox (if present) form a PDF file to set the media size. You haven't set the media size, so the default (A4 or Letter) is used. THe ViewJPEG PostScript program simply places the image on the page at bopttom left. | 08:58.09 |
| | If you want something else you either need to set the media size differently, or use scale/trasnlate to move the image on the media | 08:58.34 |
| tor7 | arya009: you could try compiling this https://raw.github.com/ccxvii/snippets/master/jpegtopdf.c and use that to create a pdf from jpeg | 08:59.19 |
| arya009 | this is going to be a dynamic solution so how can i get the media size? | 08:59.27 |
| kens | arya009 : that depends on what you want it to be | 08:59.39 |
| | ANd you don't 'get' the media size, you 'set' it | 08:59.51 |
| | see what tor7 said above though | 09:00.02 |
| tor7 | that's a very simple and easy to tweak tool with no extra dependencies that just creates the smallest possible pdf to show a jpeg file | 09:00.29 |
| arya009 | ok. Thanks a lot.. :) | 09:00.30 |
| tor7 | essentially, it just scans the jpeg for the image size, and then creates a PDF wrapper around it | 09:00.58 |
| chrisl | If you have a recent release of Ghostscript, you can do: gs -sDEVICE=pdfwrite -o stuff%03d.pdf viewjpeg.ps -c "(image.jpg) << /PageSize 2 index viewJPEGgetsize 2 array astore >> setpagedevice viewJPEG" | 09:01.06 |
| | I added the "viewJPEGgetsize" procedure a while back, so the output page can be sized to match the JPEG image | 09:02.00 |
| | arya009: ^^ | 09:02.19 |
| arya009 | @chris1 : Thanks a lot | 09:03.23 |
| tor7 | oops, I think I just spotted a bug in my jpegtopdf.c tool :( | 09:03.29 |
| arya009 | that worked... | 09:03.31 |
| | So in case of gif or png viewjpeggetsize equivalent will be available? | 09:04.32 |
| kens | No | 09:04.47 |
| chrisl | I don't think we have a png version, do we? | 09:05.14 |
| | arya009: there is an equivalent "viewGIFgetsize" that works exactly the same as the JPEG one | 09:06.20 |
| arya009 | ok. Thanks | 09:06.48 |
| chrisl | arya009: viewpbm.ps is different, but I can't remember why. With it, you use a command line param: "-dFITPAGE" I think | 09:07.52 |
| | PCX also uses the command line argument | 09:08.30 |
| arya009 | ok. gr8. Thank you guys | 09:09.02 |
| chrisl | I *think* the differences were due to the original design of the scripts, and I didn't want to rewrite them entirely to do the page fitting stuff | 09:09.34 |
| kens2 | Well, my latest fix corrects the bug we have open with Adobe. I wonder if we can get a rebate..... | 09:24.27 |
| Robin_Watts | kens2: Hopefully the test file downloader should work now. | 09:26.56 |
| kens2 | I saw your comment in irc, but I haven't got a file to try with at the moment | 09:27.13 |
| Robin_Watts | and it should be hooked into cluster run reports (when viewed from the dashboard) | 09:27.22 |
| kens2 | I'm bound to soon though, and it will be *really* handy for me | 09:27.32 |
| Robin_Watts | kens2: When using the links from bmpcmp to the test file fetcher, I have to convert from the foo.bar.baz.pdf.ppmraw.200.0 form to the real filename. | 09:50.35 |
| | And that involves a bit of guesswork. | 09:50.35 |
| | Specifically, for pdfwritten stuff, you might end up with too many .pdf's in the filename, | 09:50.46 |
| | so if you try to download a file and it doesn't work, knock a .pdf off the end and it will retry. | 09:51.08 |
| kens2 | I was assuming that .pdf.pdf and .pdf.ps wouldn't work | 09:52.39 |
| Robin_Watts | yeah. | 09:53.59 |
| | I could try and spot those cases and retry. | 09:54.07 |
| | but then we'd get .bin.ps etc too. | 09:54.18 |
| kens2 | I'm perfectly happy with just extracting the filenames and pasting into the text box | 09:54.23 |
| sss | fd | 09:54.55 |
| kens2 | It'll save me effort with winscp and navigating directory trees | 09:54.57 |
| | Robin_Watts : you are quite correct thatr .pdf.pdf does confuse the fetcher from the log, but it pops up the text box, and its easy to remove the extra .pdf there, so I'm very happy with that | 10:13.00 |
| Robin_Watts | cool. At some point I may get the fetcher try to recursively remove .xxx from the end of the file and retry automatically. | 10:13.31 |
| kens2 | Well, it would be a nice flourish, but this is very useful for me as it stands | 10:14.00 |
| | Good grief, this altone file is at 70Mb and still downloading.... | 10:14.23 |
| | 121Mb....Interestingly ,m it was a lot faster than my usual winscp | 10:15.21 |
| tor7 | Robin_Watts: argh. shade->use_function :( | 11:45.24 |
| Gigs- | If anyone has a few minutes to help me understand BMC/EMC/marked content... | 15:30.16 |
| | I'm not entirely clear on what it's all about. It appears to be a way to add proprietary extensions that don't necessarily need to be rendered if the consumer doesn't support it, but yet the PDF spec mentions an example of using BMC to alter a clip path, which seems to me to be something pretty important | 15:31.10 |
| Robin_Watts | Gigs-: Yes, basically everyone ignores it. | 15:31.28 |
| | Certainly gs and mupdf do. | 15:31.36 |
| Gigs- | our prinergy generated PDFs have copious amount of marked content | 15:32.13 |
| Robin_Watts | It's intended to allow things like drawing packages to leave droppings within the content streams so that when it reimports they can pick the extra information back up again. | 15:32.16 |
| Gigs- | like that 50something meg one I submitted yesterday, has page after page of content in CREO_ namespace BMC blocks | 15:32.43 |
| | would it break things to do a naieve stripping of BMC blocks? Assuming you at least handle nesting so you don't leave fragments? | 15:33.53 |
| Robin_Watts | Gigs-: It would not harm anything to do a stripping of BMC/EMC. | 15:34.27 |
| | I don't think even nesting is a problem. | 15:34.38 |
| Gigs- | well in theory the spec allows BMC stuff BMC stuff EMC stuff EMC if you did a really naieve algorithm it would leave the final "stuff EMC" | 15:35.15 |
| | also I clearly can't spell naive | 15:35.30 |
| Robin_Watts | Gigs: No, just remove all "tag BMC" and all "tag prop BMC" and all "tag MP" and all "tag prop DP" and all "EMC" | 15:36.49 |
| Gigs- | do you think it would be a good fit for a mutool feature request? Or does mutool operate on too high a level to be able to dig inside of streams? | 15:36.58 |
| Robin_Watts | And then nesting isn't an issue. | 15:37.03 |
| | Currently mutool doesn't touch stream contents (other than to decompress them). | 15:37.22 |
| | but yes, it certainly could. | 15:37.25 |
| Gigs- | what do you mean remove them? | 15:37.35 |
| Robin_Watts | I mean remove them. delete them. take them out of the file. output the same stream but with all the things I just mentioned omitted. | 15:38.24 |
| Gigs- | and leave what was between them? | 15:38.35 |
| Robin_Watts | Gigs-: Indeed. | 15:38.43 |
| | It's a reasonable thing to ask for, but I can't see us doing it in the short term, without a supported customer or a commercial customer request. | 15:39.39 |
| | We are just too busy. | 15:39.45 |
| | We'd probably look favourably on a well written patch to do it though. | 15:39.57 |
| Gigs- | I thought what was between them was the actual marked content | 15:40.57 |
| | Maybe I'm misunderstanding | 15:41.07 |
| Robin_Watts | Essentially BMC and EMC etc allows a file producer to mark regions of the content stream with tags. | 15:42.26 |
| Gigs- | but that part of the stream is still rendered by say GS even if it's tagged? | 15:42.58 |
| Robin_Watts | for instance a word processor might tag sections of the stream according to which 'story' it came from. | 15:43.08 |
| | Things like gs and mupdf completely ignore the tags and render everything. | 15:43.19 |
| | essentially BMC and EMC are ignored by us. | 15:43.28 |
| | but we still look at the "contents" of those tags. | 15:43.39 |
| Gigs- | oh ok I'm getting it now. I was under the mistaken impression that everything contained within the tags was the proprietary stuff | 15:43.40 |
| Robin_Watts | (they could be completely unnested and we wouldn't care) | 15:43.56 |
| kens2 | No, its just a comment like 'this bit was a form'#, 'this bit is a gradient' etc | 15:44.04 |
| Gigs- | that makes more sense then with regard to the files we have, I was wondering how so much content was proprietary :) | 15:44.30 |
| | thanks for helping me understand it, though now I'm not sure I'm motivated to strip them since the savings wouldn't be too big | 15:45.09 |
| kens2 | no, it woudlnt' save much. I have a feeling tha the GS PDF interpreter doesn't pass them through, so if you do a vonversion to PDF suing pdfwrite they will vanish | 15:47.22 |
| Gigs- | yeah, we normally avoid pdfwrite because ghostscript is only about 99.9% right on our files | 15:48.23 |
| | it's a lot better than it used to be though, which is awesome | 15:48.35 |
| kens2 | 'right' can be debatable :-) | 15:48.49 |
| Gigs- | hmm, not regressing vs adobe rip lets say | 15:49.08 |
| | though I get what you mean, files do funny things sometimes | 15:49.26 |
| kens2 | well it depends what you mean, and what you expected. | 15:49.30 |
| | If you do a conversion to PDF/a-1 then the colour spaces change for example | 15:49.47 |
| Gigs- | speaking of pdfwrite, we still have about 40 lingering DCS2 files that we can't coax prinergy into converting to PDF | 15:50.20 |
| | for ancient history background, a DCS2 file is a bunch of gray 8-bit EPSs concatented together | 15:50.46 |
| | one per separation | 15:50.51 |
| kens2 | Desktop Color Separation | 15:50.53 |
| | Not Document STructuring Convention | 15:51.04 |
| Gigs- | heh yeah acronym conflict | 15:51.14 |
| kens2 | Stupid to reuse an existing acronym but there you go | 15:51.15 |
| Gigs- | blame quark | 15:51.26 |
| kens2 | I blame Quark for everything if I can ;-=) | 15:51.39 |
| Gigs- | you think there's a way to roll those 8-bit gray seps into a proper pdf with tint transforms to composite right? | 15:51.55 |
| kens2 | Hmm..... | 15:52.12 |
| Gigs- | I think I asked in the past, but with only 40 left, a manual process is more plausible | 15:52.18 |
| kens2 | Its been a long time since I looked at DCS2 | 15:52.22 |
| Gigs- | well just think of it as pre-separated EPS pages | 15:52.35 |
| kens2 | recreating a composite PDF would be tricky | 15:53.00 |
| Gigs- | the DCS file does have comments at the top to specify CMYK tint transforms | 15:53.22 |
| | (which is accurate... some of the time) | 15:53.32 |
| kens | network fail :( | 15:53.57 |
| Gigs- | the DCS file does have comments at the top to specify CMYK tint transforms | 15:54.02 |
| | (which is accurate... some of the time) | 15:54.03 |
| kens | I'd have to re-read the spec, it doens't sound trivial, and without a commercial customer asking for it (and it being rather obselete) I doubt we'd do it. | 15:54.43 |
| Gigs- | oh no I'm not asking for a tool really, just if you have an idea for a manual process | 15:55.05 |
| | with so few left I could hack something by hand if needed | 15:55.19 |
| kens | Offhand, no, I'd have to think about it a bit | 15:55.37 |
| Gigs- | ok no problem, don't spend much time on it | 15:55.55 |
| | I've been meaning to play with illustrator | 15:56.30 |
| | see if I can import the seps and tint them and combine | 15:56.39 |
| | that may work | 15:56.45 |
| kens | Maybe, I can';t remember how the seps are defined, I'd have to look at it again, its been a long tgime | 15:57.10 |
| ray_laptop | mvrhel: for the logs. If I don't respond here, please call me. I see the .poppdf14devicefilter following the comment line % todo: discard | 16:01.47 |
| | mvrhel: so it seems that if you add a pdf14 compositor action to "abort" or "discard" the pdf14 information, you should be OK. | 16:02.41 |
| | It isn't obvious to me if anything has to be done in devices/vector/gdevpdft.c for the pdf14 device. It doesn't do anything with PDF14_POP_DEVICE now | 16:05.30 |
| | that's something that kens can think about: What happens if we error out while in the middle of transparency operations, such as a mask or group. | 16:06.30 |
| | Gigs: I saw comments about combining gray eps separations into a "proper" PDF. | 16:08.18 |
| | Gigs: it shouldn't be too hard to come up with the tint transform proc based on the CMYK numbers. And I assume that each spot color separation also has it's name to use as a spot color name somewhere in the DSC as well | 16:10.26 |
| kens | Then we throw an error I would think | 16:11.34 |
| | Because pdfwrite just preserves this stuff normally | 16:11.58 |
| ray_laptop | Gigs: but once separations are generated, you no longer have the original "overprint" information for the seps, so I am not sure how that would need to be handled | 16:12.01 |
| | kens: OK. Thanks. mvrhel and I discussed this a bit yesterday -- to handle the fuzzing bugs with transparency where the pdf interpreter returns true from the showpagecontents with the pdf14 device having been pushed | 16:13.53 |
| kens | pdfwrite doesn't use pdf14 usually, only when flattening transparency | 16:14.27 |
| ray_laptop | kens: he has to clean up all of the buffers and decouple the device WITHOUT trying to dump the page image | 16:14.37 |
| kens | It has its own transparency handlign stuff | 16:14.37 |
| ray_laptop | kens: for the pdfwrite device, I'm concerned with whether or not it needs to do anything if it gets a PDF14_ABORT (or whatever mvrhel calls it) | 16:15.52 |
| kens | Pass, its all new to me | 16:16.11 |
| ray_laptop | kens: so just returning an error makes sense there | 16:16.12 |
| | kens: yes, it's new -- mvrhel and I just talked about it yesterday PM for the first time | 16:16.42 |
| kens | OK, well I guess I owuld need to know more about it.In general, since pdfwrite doesn't use the pdf14 compositr I can't see it being a problem. For the cases where we are flattening the transparency, presumably pdfwrite will be given an error. | 16:17.42 |
| ray_laptop | kens: it's when we aren't flattening the transparency that we'd need to handle the new PDF14 compositor action appropriately | 16:20.23 |
| | kens: so what the appropriate action is, is the question. | 16:20.51 |
| kens | ray_lapto: p if we arent' flattening transparency then we don't use the pdf14 compositor | 16:23.28 |
| | pdfwrite handles transparency itself | 16:23.38 |
| Gigs- | ray_laptop: I'm not sure it was handled really. | 16:37.30 |
| | ray_laptop: as long as you put the plates on the press in the right order, it didn't matter as much for computer screen display I guess | 16:38.21 |
| | and the CMYK values were just handled as subtractive for display | 16:39.16 |
| | nothing was opaque | 16:39.44 |
| ray_laptop | Gigs: I guess the separations would just assume overprint true and that if any other layers were supposed to have been written with overprint false, they will have been blanked when the seps were created | 16:42.38 |
| Robin_Watts | paulgardiner, tor7: Am I going blind? Do we have no function to free annotations? | 16:45.42 |
| | I can see it at the pdf level, but not at the fz level. | 16:46.26 |
| | Looks like they die with the page. | 16:52.09 |
| | That's a pain in the ass. | 16:52.17 |
| tor7 | Robin_Watts: I have no idea | 16:53.19 |
| kens | OK time to go, night all | 16:57.13 |
| Robin_Watts | ray_laptop: What are your plans re Maui? Are you coming with family etc? | 17:16.35 |
| mvrhel_laptop | ok that was messed up | 17:31.54 |
| Robin_Watts | ? | 17:32.13 |
| mvrhel_laptop | I have been having a whole conversation with myself on IRC for the last half hour and none of it was logged and no one was answering | 17:32.20 |
| | I finally got suspicous | 17:32.27 |
| Robin_Watts | ha! | 17:32.30 |
| mvrhel_laptop | and shut down my IRC cleint | 17:32.35 |
| ray_laptop | Robin_Watts: no, my wife and kids have to stay here. It's my daughters holiday show choir performances on Dec 5, 6 and 7 plus I really can't pull them out of school during the week to make it worthwhile | 17:32.36 |
| mvrhel_laptop | and restarted | 17:32.38 |
| ray_laptop | mvrhel_laptop: welcome to the real IRC :-) | 17:32.54 |
| Robin_Watts | ray_laptop: You could stay the week after? | 17:32.56 |
| mvrhel_laptop | ray_laptop: please dont do anywork on the transparency stuff | 17:33.02 |
| ray_laptop | Robin_Watts: no, there are tests etc. | 17:33.10 |
| mvrhel_laptop | it is all coming together nicely for me | 17:33.11 |
| Robin_Watts | ray_laptop: Ah, rats. | 17:33.35 |
| ray_laptop | mvrhel_laptop: np. I was just looking at pdf_main.ps -- I saw where it has the % todo: discard | 17:33.40 |
| mvrhel_laptop | ray_laptop: yes got that in there | 17:33.51 |
| Robin_Watts | mvrhel_laptop: fetcher should work with all files now, and it's linked in automatically to bmpcmp and regression results. | 17:34.11 |
| mvrhel_laptop | I was going to use discard_transparency_layer as the proc to the transparency device to have it clean its self up | 17:34.12 |
| | as far as I can tell that is not being used any where | 17:34.24 |
| ray_laptop | mvrhel_laptop: one of my fuzzing segfaults now appears to be in your area, and another in the GC (chrisl) | 17:34.29 |
| mvrhel_laptop | Robin_Watts: great | 17:34.32 |
| | ray_laptop: I left you a phone message also | 17:34.48 |
| | about Michael Chang's message | 17:35.01 |
| ray_laptop | mvrhel_laptop: oops. phone isn't here. I better go get it. | 17:35.07 |
| mvrhel_laptop | hopefully that did not go in the bit bucket too | 17:35.11 |
| | I was really starting to get a complex there for a bit | 17:35.32 |
| ray_laptop | mvrhel_laptop: I don't see a message from Michael Chang. Was support cc'ed ? (or me?) | 17:37.02 |
| mvrhel_laptop | there were a pile of people on the email | 17:37.43 |
| | hold on | 17:37.47 |
| | you were on there directly | 17:38.14 |
| | september 17th | 17:38.28 |
| | 1:41 pm | 17:38.34 |
| ray_laptop | mvrhel_laptop: strange. What's the subject (gmail doesn't pull it up) | 17:38.35 |
| mvrhel_laptop | RE: PDF Transparency Problem on Venus / Mercury | 17:38.42 |
| | and then I had asked you about it on IRC yesterday or the day before I think | 17:39.07 |
| | maybe I was chatting to the ether that day too | 17:39.17 |
| ray_laptop | the last email from him in my gmail (searching mail spam and trash) was 2/24/2012 | 17:39.19 |
| mvrhel_laptop | ok let me foward to you and support | 17:39.33 |
| | sent | 17:39.51 |
| | ray_laptop; so on the IRC logs I had put links to a couple commits that they may need | 17:41.22 |
| | but I don't know what you gave them so far or what snapshot they have | 17:41.35 |
| | let me check the logs | 17:41.41 |
| ray_laptop | mvrhel_laptop: I found it. It was from a different (new) email host that wasn't white listed | 17:41.50 |
| mvrhel_laptop | oh ok | 17:42.02 |
| | the commits are listed in here | 17:42.10 |
| | http://ghostscript.com/irclogs/2013/09/18.html | 17:42.11 |
| | middle of page | 17:42.21 |
| | ray_laptop: should I will reply to him now, that you and I are discussing what they need? or do you just want to take it from here? | 17:43.41 |
| | on thing, is that this will *not* give real overprint simulation for every case with spot colors | 17:44.08 |
| | that is not possible without a real planar device | 17:44.15 |
| | as is mentioned in one of the commits ray_laptop | 17:44.24 |
| | i.e. like psdcmyk or tiffsep | 17:45.05 |
| ray_laptop | mvrhel_laptop: I'll reply. Thanks for the heads up. At least I've rescued the message and dusted it off (there was some spam sticking to it ;-) _ | 17:59.27 |
| mvrhel_laptop | ray_laptop: ok great | 17:59.46 |
| | thanks | 17:59.48 |
| | dusting off cobwebs on all the pdf14 structures that need to be cleaned up with a proper abort | 18:44.54 |
| | blah going to take a break from this rabbit hole | 19:00.28 |
| | bbiaw | 19:00.34 |
| sebras | Robin_Watts: I'm looking at zeniko's fz_read patch. in one place we try to read 20 chars and check the return value, in another the return value is (void)ed away. I think this ought to be consistent and probably checvked in both places. | 21:05.26 |
| | what is zenikos preferred way of communication? mail? I rarely see him here. | 21:06.46 |
| | Forward 1 day (to 2013/09/20)>>> | |
IRC Logs