| | <<<Back 1 day (to 2011/08/18) | 2011/08/19 |
| ecadre | email sent :-) | 00:05.15 |
| ecadre | goes to bed | 00:18.03 |
| mvrhel2 | darn. forgot to fix the warning in my last commit | 05:22.23 |
| ray_laptop | mvrhel2: I've got a patch in clusterpush that does the imager_state_finalize. I see it freeing the icc_link_cache on the way out, and it doesn't seem to leak semaphore handles | 06:00.13 |
| mvrhel2 | ray_laptop: that is great! | 06:00.26 |
| | I am trying to figure out 691800 right now and getting stumped | 06:01.01 |
| | very weird things going on between pdfwrite and transparency | 06:01.15 |
| | ray_laptop: who was the guilty party in incrementing but not decrementing the objects in the graphic state | 06:02.55 |
| | bed time | 06:18.27 |
| | good night all | 06:18.29 |
| femfum | bye | 11:48.07 |
| | hi again... | 12:05.58 |
| | could someone answer a question about the two operators... 'setblackgeneration' and 'setundercolorremoval' ...related to their apparent no-work using the device 'bitcmyk' in RGB to CMYK conversions? This is true in the all GS 9.# releases, but works well in the old 8.71 (if necessary, we have samples about this possible bug) | 12:06.12 |
| chrisl | femfum: it sounds like a bug to me - we've made *big* changes to the color workflow between 8.71 and 9.00, so it is not totally surprising. Have you tried 9.04? | 12:20.29 |
| femfum | yes, it also fails in this latest 9.04 version :-( | 12:21.49 |
| | want you see any samples? | 12:23.47 |
| chrisl | Have you tried it with different devices? Maybe tiff output? | 12:23.50 |
| kens | If its a bug then it should get a bug tracker | 12:24.15 |
| femfum | no, because I need to compute the real CMYK percentages | 12:25.03 |
| | ok, and into gs-devel list also? | 12:25.59 |
| chrisl | femfum: I only meant to check if this is a general problem, or something specific to bitcmyk | 12:26.07 |
| kens | No, just raise a bug in Bugzilla | 12:26.16 |
| femfum | ok, thanks | 12:26.35 |
| kens | OK Michael#'s problem looks like a pdfwrite bug. | 12:46.23 |
| chrisl | Which problem is that? | 12:47.27 |
| kens | Soemthing to do with transparency groups | 12:47.38 |
| | He sent me private mail about it | 12:47.48 |
| | Its to do with patterns and which CTM they use. | 12:48.11 |
| chrisl | IIRC, PDF patterns use the "wrong" CTM, don't they? | 12:48.41 |
| kens | Yes, that's the problem. | 12:49.00 |
| | They use the 'enclosing' CTM, or the 'parent' if you prefer that terminology | 12:49.18 |
| | pdfwrite is writing a shading (pattern) with an unscaled BBox etc. | 12:49.43 |
| | Inside a form | 12:50.17 |
| | Normally that can't happen because we unwind forms, but transparency groups (aha!) do ed up in form XObjects | 12:50.46 |
| chrisl | Another reason to find and shoot somebody in Adobe..... | 12:51.10 |
| kens | Yes, one of the best.... Though I wonder if its a bug that has been preserved in amber | 12:51.35 |
| | Not an excusse, just a different vitim | 12:51.54 |
| | victim | 12:52.00 |
| chrisl | I haven't checked the spec recently - it was certainly contrary to spec at one point | 12:52.19 |
| kens | I admit its all very gray from what I recall. | 12:52.36 |
| | And deeply ugly | 12:52.56 |
| chrisl | "Very gray and deeply ugly" sums up much of PDF these days | 12:53.39 |
| kens | :-) | 12:53.46 |
| chrisl | tkamppeter: ping? | 12:54.22 |
| tkamppeter | hi | 13:30.31 |
| chrisl | tkamppeter: hi. I was wondering if you had any feel for how much use the contrib/pcl3 device gets in the "real world"? | 13:34.10 |
| tkamppeter | chrisl, unfortunately not. Probably it is used only for very old HP inkjets. Now HP already supports their printers with HPLIP for years. And the new printers even need HPLIP. | 13:36.29 |
| | chrisl, what is the problem of pcl3? | 13:36.47 |
| chrisl | tkamppeter: I have a bug open saying there is a newer version than we ship, but it's going to be a fair amount of work to get it working (on top the patch you did for the newer GS API), and I'm trying to decide whether the time is worth spending | 13:38.01 |
| tkamppeter | chrisl, what is the bug number? | 13:42.12 |
| chrisl | tkamppeter: Bug 689283 | 13:42.28 |
| tkamppeter | Perhaps one could find out what changed between the pcl3 version used in GS and the most recent version of pcl3. Perhaps it is easier applying that patch than removing the old version and inserting the new version. | 13:46.22 |
| | chrisl, ^^ | 13:46.31 |
| chrisl | tkamppeter: possibly - I sort of feel, as it's a "contrib" device, it ought not to need our time spent on it.... but maybe that's just me! | 13:47.38 |
| ray_laptop | finally got my cable internet installed at home. 20Mb/s down vs. 2.5 with DSL (1.0 up vs. .4) :-) | 14:00.21 |
| chrisl | ray_laptop: it does put a fresh perspective on what you can do online - easy to get used to, as well! | 14:01.36 |
| | tkamppeter: actually, that bug is wrong - contrib/pcl3 is at the latest version - I think the reporter got confused because "reports.txt" file he refers to has been updated outside of the distributed archive. | 14:09.57 |
| tkamppeter | chrisl, OK, then you can close the bug. | 14:10.45 |
| chrisl | tkamppeter: I think I will pull in the latest reports.txt, might save the same confusion arising again. | 14:11.22 |
| tkamppeter | I have a question to p22write, does it flatten all input file pages to full-page bitmaps? Is there a way to make GS generate text-searchable PS from PDF files? | 14:11.39 |
| | chrisl, OK. | 14:11.58 |
| ray_laptop | tkamppeter: did you mean ps2write ? | 14:12.01 |
| tkamppeter | Yes, ps2write. | 14:12.17 |
| kens | high level like pdfwrite | 14:12.30 |
| ray_laptop | tkamppeter: but neither pswrite, nor ps2write flattens pages to images (unless they have transparency) | 14:12.31 |
| | tkamppeter: the ps2write output is actually valid PDF with a procset to interpret the following PDF using PS level 2 | 14:13.24 |
| kens | Not quite, not anymore | 14:13.44 |
| ray_laptop | tkamppeter: of course elements of PDF that cannot be represented in PS Level 2 are 'down converted' (such as shadings) | 14:14.15 |
| | kens: yes, it's been a while since I looked at it | 14:14.27 |
| kens | :-) | 14:14.31 |
| tkamppeter | ray_laptop, see https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/817049/comments/14 | 14:14.35 |
| ray_laptop | kens: I'm sure the DSC mangling messed things up a bit | 14:14.44 |
| tkamppeter | I have tested with this PDF as input: https://bugs.freedesktop.org/attachment.cgi?id=50285 | 14:15.58 |
| ray_laptop | tkamppeter: that link mention ps2ps (not ps2ps2) the pswrite device does turn text into bitmaps | 14:16.03 |
| kens | ray_laptop : sort of, I took the opportunity to strip out a load of irrelevant stuff when reformatting it | 14:16.26 |
| tkamppeter | ps2ps and ps2ps2 have no relevant differences in current GS. They both use ps2write, also pdf2ps uses ps2write. | 14:20.03 |
| ray_laptop | tkamppeter: ps2ps2 is supposed to use -sDEVICE=ps2write | 14:23.58 |
| | tkamppeter: I had forgotten that we changed ps2ps to also use ps2write | 14:24.53 |
| kens | :-) | 14:33.27 |
| tkamppeter | kens, ray_laptop, I jhave checked and all scripts use ps2write, so my file was converted by ps2write. Can you check the input file which I have linked above whether it can convert into searchable PS? | 14:42.58 |
| kens | the input seems to be HTML | 14:43.38 |
| chrisl | strange, the font(s) seem to end up as Type 3 in the Postscript, with a custom encoding. | 14:57.53 |
| ray_laptop | tkamppeter: what's the bug number on freedesktop ? | 14:58.08 |
| tkamppeter | ray_laptop, https://bugs.freedesktop.org/show_bug.cgi?id=40076 | 15:03.50 |
| ray_laptop | tkamppeter: thanks. | 15:03.57 |
| tkamppeter | ray_laptop, chrisl, kens, the input file is the third attachment of the Freedesktop bug. | 15:04.46 |
| ray_laptop | tkamppeter: I have it. It has text in the original as CIDFontType2 with 'Identity' encoding, so we see text as stuff like: | 15:08.49 |
| | [ (\000\001\000\002\000\003\000\003\000\004\000\005\000\006\000\007) -1 (\000\b\000\t\000\n) -1 (\000\013) ]TJ | 15:08.51 |
| chrisl | kens: does -dNOTRANSPARENCY work with ps2write? The device doesn't override the setting somehow? | 15:10.06 |
| kens | no idea | 15:10.19 |
| ray_laptop | kens: chrisl : presumably these funky encodings are problematic for turning it back into searchable text. | 15:10.34 |
| | chrisl: -dNOTRANSPARENCY i handled at the PDF interp level, so it works with any device | 15:10.57 |
| | kens: there are ToUnicode entries for the embedded fonts, however | 15:11.58 |
| chrisl | ray_laptop: the funky encodings may be a problem for making it searchable, but doesn't explain why it ends up as a Type 3 bitmap font | 15:11.58 |
| ray_laptop | chrisl: I agree | 15:12.22 |
| | I'll leave that up to kens or you. If you still have trouble getting the 'firefox.pdf' attachment, let me know and I'll email it | 15:13.04 |
| kens | mail it to me please | 15:13.17 |
| chrisl | ray_laptop: that's why I was asking about disabling transparency - the text seems to have transparency settings (according to Acro pre-flight) | 15:13.18 |
| ray_laptop | chrisl: pdf_info.ps doesn't report it as having transparency | 15:15.13 |
| tkamppeter | pitti, for me it looks more that the buildds does something wrong. See | 15:15.27 |
| | https://launchpadlibrarian.net/77487052/buildlog_ubuntu-oneiric-i386.m2300w_0.51-0ubuntu13_FAILEDTOBUILD.txt.gz | 15:15.34 |
| | and search "compressed-ppds" in there. | 15:15.53 |
| chrisl | ray_laptop: well, could be Acro preflight being cr*p - as we know it is! | 15:15.57 |
| tkamppeter | sorry | 15:16.24 |
| ray_laptop | chrisl: gswin32c -- toolbin/pdf_info.ps /c/temp/freedesktop_bug_40076.pdf lists: | 15:16.26 |
| | Creator: cairo 1.9.5 (http://cairographics.org) | 15:16.28 |
| | Producer: cairo 1.9.5 (http://cairographics.org) | 15:16.29 |
| | Page 1 MediaBox: [0 0 595.3 841.9] | 15:16.31 |
| | No system fonts are needed. | 15:16.32 |
| chrisl | ray_laptop: it definitely has transparency settings in the PDF file - and we know cairo puts *everything* in a transparency group | 15:18.36 |
| ray_laptop | chrisl: interestingly, however, object 11 (Type /Page) has /Group << /Type /Group /S /Transparency /CS /DeviceRGB >> /Resources 2 0 R >> | 15:20.17 |
| chrisl | ray_laptop: so pdf_info.ps is missing some information. | 15:21.09 |
| ray_laptop | mvrhel2: do you know offhand if we are missing transparency for that file ? (-Zv doesn't show any transparency actions) | 15:21.23 |
| | chrisl: not just pdf_info.ps (it uses the same 'pageusestransparency' as the PDF interp does | 15:21.49 |
| chrisl | Interestingly, if I convert pdf->pdf, I get a searchable PDF out of pdfwrite | 15:22.34 |
| ray_laptop | chrisl: mvrhel2: I don't see it actually doing anything with transparency, despite the /Group dict for the page | 15:22.35 |
| | kens: chrisl: do we assume that the Level 2 PS can accept Type 42 TT fonts ? | 15:23.12 |
| ray_laptop | goes to check docs | 15:23.20 |
| kens | Yes, | 15:23.28 |
| mvrhel2 | sorry I was down the hall making breakfast | 15:23.54 |
| ray_laptop | chrisl: kens: the ps2ps2.htm _does_ mention: If the target printer can't handle a particular font type, ps2write converts the fonts into a bitmap fonts representation, using the resolution specified when ps2write is invoked. In particular this can happen with CID fonts, which are not Postscript Level 2 objects. In general these are converted to multiple instances of other font types) | 15:24.42 |
| mvrhel2 | kens, before you leave for the evening, do you mind if I push 691800 to you? | 15:25.38 |
| ray_laptop | chrisl: I am going to try it with -dHaveTrueTypes=true | 15:25.53 |
| kens | Its miine | 15:25.59 |
| chrisl | That could be the problem, then. I'd still expect the text to selectable, but I'd expect the character codes to be "nonsense". | 15:25.59 |
| mvrhel2 | being a pdfwrite issue, I think you will have better luck with it | 15:25.59 |
| | kens: was that to me? | 15:26.35 |
| kens | yes | 15:26.40 |
| mvrhel2 | ok. great thanks | 15:26.45 |
| | kens, do you want me to attach the simple example files? | 15:28.01 |
| kens | I already have them | 15:28.15 |
| mvrhel2 | ok | 15:28.29 |
| ray_laptop | chrisl: kens: doesn't help. Still get bitmaps | 15:28.33 |
| chrisl | ray_laptop: I think you must be right about the CID font limitation - as I say, I'm surprised the text isn't selectable, though | 15:29.07 |
| mvrhel2 | brb | 15:29.13 |
| ray_laptop | kens: I sent the file | 15:29.48 |
| kens | ok | 15:30.23 |
| ray_laptop | looks like the only reason cairo is using CIDFontType2 is so they can use UTF-16 string data :-( | 15:30.45 |
| kens | Then they will always get type 3 | 15:31.06 |
| | I have to run, night all | 16:13.44 |
| chrisl | alexcher: ping | 16:38.58 |
| alexcher | chrisl: pong | 17:03.50 |
| chrisl_away | alexcher: sorry, I have to head out - I sent you a mail about it | 17:05.43 |
| alexcher | chrisl: I'm looking. | 17:06.46 |
| ray_laptop | alexcher: I just posted a stackoverflow answer about creating a PDF with filenames in it from a bunch of individual files. When you get a chance, could you look at my PS code to make sure I didn't miss something ? (NOT urgent) | 17:09.17 |
| alexcher | ray_laptop: please email me your PS program. | 17:21.05 |
| | ray_laptop: or URL of the page. | 17:24.08 |
| mvrhel2 | whoo-hoo. I have less than 50 bugs now in my list | 17:44.26 |
| henrys | we'll have to find you more code to manage ;-) | 17:45.48 |
| mvrhel2 | I need to get back to the planar color stuff now | 17:46.38 |
| | I also want to get the simple cmm in place | 17:46.58 |
| henrys | yea the planar schedule is not so good, I don't look forward to the email with the customer but I can't think how we could have done better. | 17:48.27 |
| mvrhel2 | sorry about that | 17:48.44 |
| ray_laptop | alexcher: the snippets are on the stackoverflow post. The URL is: http://stackoverflow.com/questions/7102090/combining-pdf-files-with-ghostscript-how-to-include-original-file-names | 17:50.59 |
| henrys | mvrhel2:no problem don't worry about it. | 17:52.51 |
| alexcher | ray_laptop: the code looks fine. | 17:59.35 |
| mvrhel2 | great. I created a simple pattern fill to test out the plank device with the planar code and it doesnt even render correctly going out to ppmraw | 18:08.57 |
| | very odd | 18:09.11 |
| | ray_laptop: can I send you a file to check? | 18:09.48 |
| ray_laptop | mvrhel2: SURE | 18:11.41 |
| | alexcher: thanks | 18:14.07 |
| mvrhel2 | ray_laptop: ok sent it | 18:16.32 |
| | atcually that worked now | 18:18.35 |
| | to ppmraw | 18:18.38 |
| | what is going on | 18:18.46 |
| | ray_laptop: so try the file I sent going to ppmraw and to tiff24nc | 18:19.51 |
| | going out to a tiff device does not render correctly for me | 18:20.18 |
| | tiff24nc gives all black | 18:20.32 |
| | tiff32nc gives all white | 18:22.49 |
| | ray_laptop: the file renders painfully slow out to psdcmyk | 18:25.35 |
| mvrhel2_ | well the psdcmyk file is OK | 18:33.00 |
| | oh it looks like the bounding box for this thing is huge | 18:33.21 |
| | aha. at 72dpi output is 14400 by 14400 | 18:33.45 |
| | likely a mem issue with the tiff output | 18:34.01 |
| | ray_laptop: don't spend any more time on this | 18:34.20 |
| | if you have at all | 18:34.26 |
| | I dont understand why AR does not render it this large though | 18:35.43 |
| ray_laptop | mvrhel2_: doesn't look like a mem issue -- even fails (all black) with -r10 | 18:40.06 |
| mvrhel2_ | ok | 18:40.17 |
| | psdcmyk works | 18:40.20 |
| | but the size is huge | 18:40.23 |
| | AR the size is reasonable | 18:40.28 |
| | ray_laptop: I think there is a bug here. who would be best to hand this one to | 18:41.17 |
| mvrhel2_ | goes back to the drawing board to create a simple file for his testing | 18:46.49 |
| ray_laptop | mvrhel2_: try -dUseCropBox that's what AR does by default. -dPDFDEBUG shows: /CropBox [6800.5 6899.5 7600.5 7499.5 ] /MediaBox [0.0 0.0 14400.0 14400.0 ] | 18:48.11 |
| mvrhel2_ | aha | 18:48.49 |
| | about 3 orders of magnitude faster | 18:49.11 |
| ray_laptop | mvrhel2_: or edit the file to fix the MediaBox | 18:49.13 |
| | but why it is black with tiff, I don't know | 18:50.02 |
| mvrhel2_ | ok. so yes, even with the cropbox the tif still comes out black | 19:01.43 |
| | weird | 19:01.44 |
| henrys | leaving early today and won't be back until Sunday - pikes peak ascent is tomorrow. | 19:03.00 |
| mvrhel2_ | nice | 19:03.16 |
| | have fun! | 19:03.19 |
| ray_laptop | henrys: good luck. Just remember to check your radiator level before going up ;-) | 19:03.25 |
| | henrys: you _are_ driving and not doing something like running or biking, right ? | 19:04.38 |
| henrys | we actually do run up the mountain ... that's the plan anyway | 19:05.07 |
| | http://www.pikespeakmarathon.org/ | 19:05.25 |
| mvrhel2_ | wow | 19:05.59 |
| | impressive | 19:07.12 |
| henrys | this is my first time - my goal is not to suffer the humiliation of rescue. | 19:08.13 |
| mvrhel2_ | well good luck | 19:14.40 |
| The98 | hi! | 19:18.12 |
| | I have a .pdf file which can't be reproduce by GS, should I upload it somewhere so you tell the reason of this? | 19:20.09 |
| mvrhel2_ | bugs.ghostscript.com | 19:20.25 |
| | henrys: so the plank device in general has issues with patterns that needs to be resolved | 19:21.09 |
| | basically the tiling code is set up to do chunky | 19:22.17 |
| | lunch time now | 19:22.58 |
| | bbiaw | 19:22.59 |
| robin_watts_mac | henrys: Good luck! | 23:49.51 |
| | Forward 1 day (to 2011/08/20)>>> | |
IRC Logs