| | <<<Back 1 day (to 2011/09/26) | 2011/09/27 |
| NoSu | Hi guys, is there a way to remove or edit the current cropbox etc of a pdf with ghostscript I tried doing this: http://pastebin.com/qXU6ETVJ with it just pending another cropbox to the pdf nfo. | 01:13.20 |
| | which it only obeys the first cropbox in the document | 01:14.01 |
| | which is not the cropbox that gs added | 01:14.14 |
| | If I manually edit that first cropbox out of the document the boxes are then used properly :( | 01:15.35 |
| | oops wrong pastebin corrected the original pdf line: http://pastebin.com/RCLY3VJ1 | 01:28.40 |
| marcosw_ | henrys: you around? | 01:36.55 |
| henrys | yes | 01:37.30 |
| | what happens with all these machines while you and miles are tooling around mexico? | 01:38.01 |
| marcosw_ | My wife will be in charge of resetting our cable modem. Comcast changed IP addresses on me today and so the cable modem needed to be power cycled. | 01:39.10 |
| henrys | sounds good. | 01:39.51 |
| NoSu | henrys, any help with this? http://pastebin.com/RCLY3VJ1 | 01:40.24 |
| marcosw_ | I have a question re. a customer who I can't find in the customer list, they sent an email with the subject: "Possible bug in PCL2PDF transform version 9.04". | 01:41.17 |
| | Are they a customer? | 01:41.33 |
| henrys | NoSu:did you test this against adobe? - if ours is different report a bug. | 01:42.42 |
| | bugs.ghostscript.com | 01:42.47 |
| | marcosw_:they are a customer do you need the number or wanted verify? | 01:44.28 |
| NoSu | are you personally able to use gs to change the cropbox dimensions? when the pdf already has a cropbox. | 01:44.29 |
| | not sure I understand how to "test against adobe" | 01:45.12 |
| henrys | what is the behavior when you open the file in the free adobe reader? | 01:45.31 |
| marcosw_ | I found them by looking for other bugs from them. They are #460. I'll email Joann and ask her to change/add their company name. | 01:45.51 |
| henrys | the cropbox is inheritable so it should be fine. | 01:47.09 |
| NoSu | it uses the first cropbox that it doesnt remove when you open it in adobereader | 01:47.45 |
| | and unfortunatly the first one was the one from before gs pended its cropbox after it | 01:48.13 |
| henrys | NoSu if it doesn't match adobe you report a bug at bugs.ghostscript.com and we'll likely fix it. | 01:48.40 |
| NoSu | are you sure my script is correct before I report a bug? | 01:49.09 |
| henrys | marcosw_:the domain name of the email is a subdivision of the company I think the company name is okay. | 01:50.29 |
| marcosw_ | maybe I'm more confused than I should be. Are they in fact customer #460? | 01:51.11 |
| henrys | they aren't a secret customer infoprint is a subdivision of IBM. maybe you gave me the wrong subject | 01:51.54 |
| marcosw_ | henrys: you might want to try opening infoprint.com in a web browser, I don't think they are a division of IBM. | 01:53.26 |
| | or did Ricoh buy IBM (or vice-versa)? | 01:53.46 |
| NoSu | henrys, does that script chuck look proper on how you would go about editing the cropbox? | 01:55.42 |
| henrys | I don't understand the financial the printer building I pass each day says Ricoh/IBM | 01:55.48 |
| NoSu | every time i see something related to Ricoh it reminds me of that ricolas breath mint comercial | 01:56.41 |
| henrys | Tom gets filed under IBM though | 01:56.42 |
| | NoSu:if your pdf renders differently (ibm vs. adobe) file a bug. We don't want to look at your script. | 01:57.31 |
| NoSu | that makes little to no sense but ok. | 01:58.13 |
| marcosw_ | The internets say that InfoPrint was a joint venture of IBM and Ricoh but is now a "fully owned subsidiary of Ricoh". | 01:58.14 |
| henrys | I guess you can ask miles if he wants to file things differently. | 01:59.09 |
| NoSu | 10. | 02:01.09 |
| | gswin64c.exe ^ | 02:01.09 |
| | 11. | 02:01.09 |
| | -o output.pdf ^ | 02:01.09 |
| | 12. | 02:01.09 |
| | -sDEVICE=pdfwrite ^ | 02:01.11 |
| | 13. | 02:01.13 |
| | -dPDFSETTINGS=/prepress ^ | 02:01.14 |
| | 14. | 02:01.17 |
| | -c "[/CropBox[32.4 43.2 937.554 1672.56]/BleedBox[32.4 43.2 937.554 1672.56]/ArtBox[32.4 43.2 937.554 1672.56]/MediaBox[0.0 0.0 969.954 1715.76]/TrimBox[32.4 43.2 937.554 1672.56] /PAGES pdfmark" ^ | 02:01.19 |
| henrys | NoSu:we just focus on pdf or postscript problems, fixiing scripts and programs is very time consuming once you get sucked into it. Somebody else might help. | 02:01.20 |
| NoSu | 15. | 02:01.22 |
| | -f input.pdf | 02:01.24 |
| | its not a script | 02:01.30 |
| | minus those numbers | 02:01.58 |
| | its just the gs command | 02:02.05 |
| | dont see how you personally wouldnt know if thats the proper way to use the gs command or not | 02:02.31 |
| marcosw_ | I just want him to change the support document to reflect the current name of the customer. Having to rely on an outdated sign to keep track of our customers seems a bit too much like giving directions that include "make left turn at the first street after the barn that is no longer there". | 02:03.42 |
| NoSu | not like I am saying I built some massive code to parse the meaning to life or something | 02:03.43 |
| henrys | oh I thought it was a large program. looks fair are the expected values passed into the resulting pdf? | 02:06.26 |
| NoSu | the pastebin was me just opening the pdf in a text editor and then pasting the line where the original cropbox was then I put the command i used with gs and then I pasted the line from the output pdf where the cropbox was | 02:08.19 |
| | it puts those values into the pdf file but I am not sure if that -c command is supposed to replace those values or just pend on to the current pdf layout for a pdf that didnt have those in it already which would be strange because i thought pdfs had to have all those values in them as a standard point of view | 02:10.44 |
| henrys | okay and what does adobe do with your pdf file? | 02:10.53 |
| NoSu | when you open the pdf after gs had its way with it in adobereader you still see the full page because it does not seem to edit the already existing crop box in the pdf it just seems to pend another cropbox after the first one | 02:13.18 |
| | pdf readers only use the first cropbox and then ignore the second one that gs pended onto the first one | 02:13.52 |
| | so I am unsure if I am using the command correctly | 02:14.21 |
| henrys | I see let me check something. | 02:15.08 |
| NoSu | is it supposed to edit the current pdf values | 02:15.24 |
| | if I remove the first cropbox it will then use the following cropbox that gs added properly | 02:16.19 |
| henrys | I am not sure why you are using pdfmark did you read Use.htm CropBox and PDFFitPage? | 02:17.19 |
| NoSu | where do those options acuatlly allow you to set the demensions of the cropbox I think those commands are just to enable it to use those boxes no? | 02:18.49 |
| henrys | pdfmark is a postscript language extension - I don't recall seeing it used with pdf input. | 02:20.02 |
| NoSu | i thought it was to modify the pdfmarkup | 02:20.33 |
| henrys | it is a postscript language extension. | 02:27.57 |
| | I guess I don't understnad | 02:30.24 |
| | have a look here http://stackoverflow.com/questions/5797841/cropping-a-pdf-adding-crop-box-using-ghostscript | 02:32.26 |
| | kens is the pdfwrite expert I wasn't aware we had these egregious uses of pdfmark in the code. Wouldn't be my choice. Another thing to break when we move to the C based pdf interpreter - sigh. | 02:33.31 |
| NoSu | when is he usually around | 02:34.18 |
| henrys | kens works euro work hours | 02:34.20 |
| NoSu | see the last comment there I am guessing thats what I am up against | 02:34.59 |
| | Yeah... pdfmark doesn't seem to be able to modify anything that already exists, it can only add to what's already there. You COULD do a "page" pdfmark instead of a "pages" pdfmark, but you'd need to know how many pages there were in the first place. OTOH, PS is a full programming language, so you could conceivably write something that would check the page count and Work Correctly. In Theory. Mark Storer May 2 at 16:56 | 02:35.01 |
| | (doesnt modify something that already exists) | 02:35.18 |
| | (It only can add to whats there) | 02:35.33 |
| | considering thats those boxes are supposed to be standardized in all pdf that would possible make using that pretty difficult anyways :/ | 02:36.43 |
| henrys | gotta go sorry I couldn't help more stackoverflow is a good source and kens will be around in about 5 or 6 hours | 02:37.43 |
| NoSu | ok thank you | 02:37.55 |
| Fandekasp | hi | 02:43.34 |
| | just tried to change my trackpad with `xmodmap -e "pointer = 3 2 1"` so that I can select text with the left clic on mupdf | 02:44.41 |
| | but it doesn't copy. I tried a ctrl-c as well, without success | 02:45.00 |
| | dammit -_- | 02:45.06 |
| henrys | some pcl bugs to start tomorrow off with, good night. | 05:05.51 |
| mvrhel2 | good night henrys. made some progress today. closed one bug and tracked down 692378 | 05:58.50 |
| kvelie | may i ask a question here plz ? | 09:51.31 |
| kens | You already have ;-) | 09:52.04 |
| Robin_Watts | Sure. | 09:52.05 |
| kvelie | :) | 09:52.10 |
| | thanks | 09:52.17 |
| tor8 | Fandekasp: doesn't copy how exactly? it's in the PRIMARY copy-buffer. have you tried middle clicking in an xterm to see whether the text gets pasted? | 09:52.39 |
| kvelie | im using gs to decrease the pdf file sizes, but for pdf 1.4 versions some text and images are not appearing due to the use of transparency | 09:53.10 |
| tor8 | Fandekasp: copy & paste on x11 is a bit more complicated, with both PRIMARY and CLIPBOARD copy-buffers | 09:53.12 |
| kens | kvelie if you are using 1.4 then transparency should be preserved. | 09:53.37 |
| tor8 | ctrl-c and ctrl-v operate on the CLIPBOARD, select and middle click operate on the PRIMARY | 09:53.46 |
| kvelie | kens im not sure if it is really preserved, when using the -dNOTRANSPARENCY option, the text appear again, and the imaage as well, but i can see black areas | 09:54.57 |
| kens | -dNOTRANSPARENCY is a directive to teh PDF interpreter to ignore transparency. It will render the file incorrectly | 09:55.36 |
| | And therefore convert incorrectly also. | 09:55.43 |
| | What version of Ghostscript are you using ? | 09:55.54 |
| kvelie | 9.04 | 09:56.08 |
| kens | Well, if you think its a bug, I suggest raising it as such at http://bugs.ghostscript.com | 09:56.26 |
| | You will need to attach the PDF file so we can look at it, and a command line to reproduce the problem. | 09:56.44 |
| kvelie | mmm thanks | 09:57.56 |
| kens | OK | 09:58.32 |
| kvelie | do u want me to send you the pdf file over here via dcc, so that you can have a quick look at it, maybe it is not a bug ? maybe it is from another factor ? | 09:58.42 |
| kens | Might as well just raise it as a bug. Its me that will look at it initially anyway | 09:59.05 |
| | It could be overprinting, there are a few problems in that aera being fixed right now. | 09:59.48 |
| kvelie | okay np | 10:00.05 |
| kens | Especially if the file uses /Separation or DeviceN colours | 10:00.09 |
| kvelie | done :) | 10:12.57 |
| kens | OK I'll go look | 10:13.12 |
| | kvelie, can you simplify the command line ? That's seriously complicated. | 10:14.25 |
| | You also have multiple calls to setdistillerparams, you only need one because it takes a dictionary | 10:14.48 |
| | Also, if you intend to set individual settings, don't use -dPDFSETTIGNS as that will override many of teh individual controls. | 10:15.15 |
| | Oh, and there's no attachment.... | 10:15.34 |
| | As regards Acrobat, if the file contains transparency and you go to PostScript, tehn teh transparent areas will be converted to images. GS will dothis too if you use ps2write instead of pdfwrite as the device. | 10:16.31 |
| | kvelie, still no attachment on the bug report. Can't do much without seeing the file. | 10:23.08 |
| Fandekasp | tor8: not sure, I don't have any knowledge with that. I know that xsel (tool I use to copy in the clipboard from tmux) is working with PRIMARY, SECONDARY and CLIPBOARD | 10:23.10 |
| | yes I use x11 | 10:23.25 |
| tor8 | mupdf only touches the PRIMARY | 10:24.03 |
| Fandekasp | Don't have time to play with that yet, But thanks for the advise, next time I'll look into it | 10:24.03 |
| | hmm ok, weird | 10:24.13 |
| | oh | 10:24.26 |
| | that might explain | 10:24.30 |
| | with xsel I copy in CLIPBOARD | 10:24.39 |
| tor8 | I guess we could assert ownership of both PRIMARY and CLIPBOARD | 10:25.02 |
| Fandekasp | wtf am I using CLIPBOARD instead of PRIMARY then ? makes no sense | 10:25.03 |
| | that'd be great hehe :) | 10:25.16 |
| tor8 | CLIPBOARD is the usual copy&paste buffer, for when things like gnome does ctl+c, ctl+v | 10:25.34 |
| | I find that too cumbersome, but then again, I have three real mouse buttons ;) | 10:25.48 |
| Fandekasp | loves his keyboard | 10:26.13 |
| | Ok, have to go. Thanks tor8 for your support, see you later | 10:27.35 |
| chrisl | kens: did you get a gs-commits mail for my last commit a few minutes ago? | 10:40.08 |
| kens | No. Not yet anyway | 10:40.20 |
| | No, still nothing. I have a feeling I missed some overnight too | 10:40.39 |
| chrisl | I don't seem to be getting gs-bugs mail either........ | 10:40.55 |
| kens | I'm getting those OK | 10:41.02 |
| | Just got one for updating bug #692546 | 10:41.25 |
| | Nothing in the gs-cvs archive form you today chrisl | 10:42.11 |
| chrisl | Hmm, well, my commit is definitely there - but I'm getting nothing from gs-commits not gs-bugs :-( | 10:42.52 |
| kens | Acutallu I should have got *2* from gs-bugs and only got 1. | 10:44.43 |
| | So something is definitely wrong there too. I think maybe it was gs-bugs mail I was missing overnight | 10:45.08 |
| | Yes, I have no mail for bugs #692544 or 692545 | 10:45.38 |
| chrisl | Right, well, I've no idea how to check the status for the lists, so...... | 10:45.54 |
| kens | Me neither, but something is broken | 10:46.03 |
| chrisl | I'll send a mail to marcosw_ and cc tech...... | 10:47.25 |
| kens | Fair enough | 10:47.30 |
| chrisl | Hopefully tech is still working.... if it is, my mail should be there | 10:54.11 |
| kens | Yes, got that | 10:54.49 |
| chrisl | Well, that something :-) | 10:55.15 |
| | s/that/that's | 10:55.21 |
| kens | I did also get the excessive bounces mail a few days back, but I re-subscribed. | 10:55.21 |
| chrisl | I re-subbed as well, but I don't know how the bugs and commits mailing lists would handle the same the problem. | 10:56.14 |
| kvelie | kens sorry for not replying, i just came back | 10:59.50 |
| | updated the bug with your requests | 10:59.59 |
| kens | Yes, I see that a simple -sDEVICE=pdfwrite command line drops some objects. | 11:00.34 |
| | It'll get assigned to me, it defintiely looks like a bug of some kind. | 11:00.57 |
| kvelie | ok thanks a lot | 11:02.22 |
| Robin_Watts | Holiday booked. | 11:30.10 |
| kens | Sorted then | 11:30.22 |
| Robin_Watts | yes, all worked out nicely, I think. | 11:30.39 |
| kens | is not holding breath | 11:31.10 |
| tor8 | kens: a question about PDF ToUnicode CMaps. | 13:41.59 |
| | a section with beginbfchar <34> <002d 0ad 2010> endbfchar | 13:42.19 |
| | does that mean to map 0x34 to the sequence 0x2d 0xad 0x2010 or is that supposed to be a list of alternative characters? it seems like a file from a customer looks like they expect the latter. | 13:43.05 |
| | considering that the file has an xref where all the objects supposedly live at offset 0 I'm inclined to believe that the author has no clue what he actually means. | 13:43.47 |
| Robin_Watts | tor8: Section 5.9.2 of the pdf 1.7 spec. | 14:15.18 |
| | It must use the beginbfchar, endbfchar, beginbfrange, and endbfrange operators to define the mapping from character codes to Unicode character sequences expressed in UTF-16BE encoding. | 14:15.39 |
| | That implies that's a sequence, not a set of alternates. | 14:15.57 |
| tor8 | Robin_Watts: yeah, that's what I found too | 14:16.42 |
| | so, totally broken PDF | 14:16.48 |
| Robin_Watts | I understand the 'all objects at offset 0' though. | 14:17.16 |
| | You output your PDF like that, then load it into acrobat and save it out again to fix them. Much simpler to code :) | 14:17.48 |
| tor8 | creator and producer say microsoft word and mac os x 10.6.4 quartz pdfcontext | 14:19.45 |
| | you'd hope that big companies can afford to not be that lazy | 14:19.54 |
| kens | tor8 sorry, was busy. | 14:31.33 |
| | that ToUnicode looks totally bogus | 14:32.03 |
| | ToUnicode CMaps do not follow the same rules as regular CMaps | 14:32.34 |
| | SAlso, do not go by what the spec says about them. | 14:32.49 |
| henrys | panic no coffee, I'll be back in a bit. | 14:33.02 |
| kens | The PDF refernece and ToUnicode supplement are in disagreement | 14:33.15 |
| | Acrobat follows the ToUnicode supplement IIRC | 14:33.33 |
| Robin_Watts | kens: What's the difference in this instance ? | 14:35.32 |
| | The PDF spec says, we follow the CMAP spec except for one extension. | 14:37.48 |
| kens | In this case, nothing, it was something else | 14:38.04 |
| Robin_Watts | ok. | 14:38.26 |
| kens | Sadly, I don't remember what it wqas | 14:38.29 |
| | I was just making a general observation, but that ToUnicode CMap is invalid I'm sure | 14:38.57 |
| marcosw_ | is ghostbot running correctly? | 15:35.23 |
| chrisl | marcosw_: do you get the "sudo: unable to resolve host casper" message? | 15:36.32 |
| | Oh, ghostbot seems to be running fine, yes | 15:36.46 |
| marcosw_ | yes. I treat that as a useless warning. | 15:36.51 |
| | I set hostname to casper manually in /etc/crontab | 15:37.11 |
| chrisl | I think the problem is the hostname is casper, and it should be casper.ghostscript.com, shouldn't it? | 15:37.31 |
| henrys | I thought we agreed to not allow SHARE_LCMS? | 15:38.04 |
| marcosw_ | i've set it to casper.ghostscript.com and the warning has gone away, so you are correct. | 15:38.36 |
| chrisl | henrys: I can't disable SHARE_LCMS in a previous release! | 15:38.40 |
| henrys | just noticede 692539 | 15:39.05 |
| chrisl | marcosw_: great! It was bugging me a bit.... | 15:39.14 |
| | henrys: I know, I was just going to close it | 15:39.30 |
| marcosw_ | oddly 'hostname -s' returns casper3 | 15:39.41 |
| chrisl | that is a bit strange - but, hey, let's not worry about it! | 15:40.51 |
| marcosw_ | What? Me worry? | 15:42.01 |
| chrisl | Well, I'm happy that the warning is gone :-) | 15:42.27 |
| ray_laptop | marcosw_: do any of us have the ability to log into miles, meters, inches or kilometers ? | 15:48.49 |
| marcosw_ | not at the moment, I keep meaning to set that up. currently I can't log into meters or kilometers either, since miles is the gateway and it's at my house trying to figure out why it keeps crashing at Miles' office. | 15:50.02 |
| ray_laptop | marcosw_: thanks. Which machines are where between your house and the headquarters ? | 15:52.05 |
| marcosw_ | i7, amd64, and inches are at my house, along with miles. kilometers and meters are at headquarters. | 15:53.24 |
| ray_laptop | who has 'x6' ? | 15:53.41 |
| marcosw_ | right, x6 is what amd64 is called on the cluster (it's hostname is amd64, it's cluster name is x6) | 15:54.27 |
| ray_laptop | marcosw_: oh, I see. Thanks | 15:54.49 |
| marcosw_ | btw miles, is down since it's internet connection relies on my macbookpro, which is currently with me at Peet's coffee. | 15:55.13 |
| ray_laptop | sounds a bit "fragile" (maybe "house of cards" is a better term) | 15:56.15 |
| kens | thinks its meeting time. | 16:00.14 |
| henrys | meeting time | 16:00.16 |
| marcosw_ | clusters are always fragile. The clusters are santa cruz are always have nodes crash or reboot. And they suffer from the additional problem that the nodes are all in the same room, so when the air-conditioning or power fails all of them go down. We are redundancy (except for casper3, of course). | 16:00.51 |
| henrys | I have 2 things for tor8 - xps bug and iphone gui status. | 16:01.31 |
| | make that bugs. | 16:01.39 |
| | alexcher you were going to reassign bugs according to owner? | 16:03.09 |
| | and I guess we should talk about the recent rash of segv's in the regressions. | 16:03.57 |
| alexcher | henrys: I do. but they are mostly mine already. | 16:04.02 |
| | henrys: Yes, the recent SEGV in lcms is a build issue. | 16:04.37 |
| henrys | I'm talking about the segvs in the regression emails. | 16:05.13 |
| alexcher | OK | 16:05.43 |
| kens | 2 of the files may be invalid since they are produced by pdfwrite, but that should not cause a SEGV in GS | 16:06.03 |
| henrys | marcosw:do you want to find out when those started and assign accordingly. | 16:06.46 |
| | ? | 16:06.48 |
| ray_laptop | maybe we should tout our pdfwrite as a good source of PDF files that stress readers ;-) | 16:06.56 |
| kens | If the PDF files are invlaid then a bug to me as well as the SEGV bug please | 16:06.59 |
| henrys | alexcher:I thought I noticed many problems on your bug list belonged to mvrhel2 maybe I am mistaken. | 16:08.29 |
| | that's why I put it on the agenda but if it that's wrong let me know. | 16:09.24 |
| | that's all I had this week. | 16:09.45 |
| alexcher | henrys: It's hard to say for sure before the bug is resolved. | 16:09.49 |
| marcosw_ | henrys: There are from closed bug reports, so it's likely that they never worked. | 16:10.04 |
| | ^There^They're | 16:10.16 |
| kens | But they still shouldn't cause SEGV's if we're still onthat topic | 16:10.35 |
| marcosw_ | never mind, that's not write either | 16:10.35 |
| henrys | nor right | 16:10.59 |
| alexcher | I have a question. Is Ubuntu a customer? | 16:11.23 |
| henrys | ray_laptop:are you still swamped with the customer? | 16:11.37 |
| mvrhel2 | hmm looks like my commit 36925c8 Fix for bug 692517 started the pdf.pdf segvs | 16:11.56 |
| kens | Ah, then I'll leave that one for you ;-) | 16:12.16 |
| marcosw_ | I know they should not cause seg faults, but if I do a bisect the only thing we'll find out is that they went from producing an error to producing a seg fault. | 16:12.21 |
| mvrhel2 | that was just a move of an object into stable memory | 16:12.30 |
| | very odd | 16:12.32 |
| kens | Probably re-arranged memory | 16:12.42 |
| henrys | Robin_Watts and ray_laptop:I did look briefly at the interpolation/banding stuff - looks to me like the banding stuff does the right thing but the new rotated interpolation code after banding is not right. I'll continue looking at it as time permits. | 16:13.00 |
| tor8 | henrys: iphone or android, or both? | 16:13.12 |
| henrys | but I am pretty sure it doesn't belong on ray_laptop's desk. | 16:13.23 |
| Robin_Watts | henrys: Fair enough. | 16:13.55 |
| henrys | the former first. Scott is holding up going places until he has this working on his ipad. | 16:14.17 |
| tor8 | henrys: re the xps bugs, I suspect many of the color problem files are more problems with the graphics library than the xps parser. I have seen other files where the colors when transparency is involved all funky in gxps but fine in muxps. | 16:14.24 |
| | henrys: okay. iphone gets priority then. | 16:14.47 |
| ray_laptop | henrys: still working with customer 532, but I do have bits of time while I wait for them to investigate things on their side (they currently can run stuff that I cannot). Their source code tracking is pretty awful | 16:15.07 |
| henrys | ray_laptop:well your bug list is one of the larger ones - customer wise. | 16:15.58 |
| ray_laptop | on the gxps color issues, mvrhel2 has plenty of XPS knowledge to know what's going wrong in the gs graphics lib | 16:16.32 |
| henrys | I have been actively pinging several customers working on mupdf integration and they seem to be moving forward. | 16:16.48 |
| mvrhel2 | if there are xps color issues, I am fine digging into them | 16:16.52 |
| ray_laptop | henrys: I'll start chipping at the customer bugs. | 16:16.55 |
| mvrhel2 | I am getting close to clearing my customer bug list anyway | 16:17.18 |
| henrys | tor8:well give mvrhel2 a simple example and report the bugs to him. | 16:17.40 |
| | these bugs are like real insects smash them or put them on somebody else. | 16:18.17 |
| ray_laptop | henrys: I thought someone else (you) were going to take bug 691652 | 16:18.31 |
| | was I supposed to assign it to you ? | 16:18.42 |
| henrys | yes I'll reassign it now. | 16:19.17 |
| | ray_laptop:but that isn't a customer right? | 16:19.49 |
| | anybody have anything else for the meeting? | 16:20.21 |
| | let me also reassign the interpolation/rotate thing. | 16:20.42 |
| kens | Nothing from me. | 16:20.57 |
| | Am working on text rendering modes | 16:21.04 |
| ray_laptop | henrys: you're welcome to the interpolation rotate bug | 16:21.11 |
| Robin_Watts | ray_laptop: I fear he was going to reassign it to me :( | 16:21.35 |
| henrys | Robin_Watts:it'll give me something to do in the background. I would say the rotation code should go in with punt for high level images if interpolated and non portrait. | 16:22.45 |
| marcosw_ | alexcher: your comment #1 in bug 692535 says that 9.00 works with the customer's file, is that because of the change to FreeTYpe? | 16:22.59 |
| Robin_Watts | henrys: So it'd interpolate the WHOLE image for EVERY band? | 16:23.28 |
| | What do you have against performance? :) | 16:23.39 |
| kens | Later, when we redo it, the customer thinks we are wonderful :-) | 16:24.02 |
| henrys | no it will convert the image to rectangles before banding. | 16:24.02 |
| Robin_Watts | Urgh. | 16:24.23 |
| | And we call that 'high level' images? | 16:24.35 |
| alexcher | marcosw_: Yes, the FreeType builds create a different font dictionary. | 16:24.41 |
| ray_laptop | Robin_Watts: if we punt on non-portrait interpolated images it'll interpolate _before_ the clist and just put rectangles into the clist | 16:24.42 |
| | henry typed faster | 16:24.59 |
| marcosw_ | alexcher: that's what I figured, so I won't offer to supply a patch for 8.71 :-) | 16:25.11 |
| Robin_Watts | Sounds ghastly. | 16:25.37 |
| henrys | Robin_Watts:then I will go about fixing the bug when high level images are enabled but at least we'll have the functionality in place. | 16:25.44 |
| Robin_Watts | henrys: Ah, right. | 16:25.54 |
| henrys | it can always be turned off with the NOINTERPOLATE option. | 16:26.13 |
| alexcher | marcosw_: The customer should patch his PS generator, or install an idiom. | 16:26.14 |
| Robin_Watts | In marcosw_'s latest list of plank vs pamcmyk4 diffs... | 16:26.36 |
| alexcher | marcosw_: Unfortunately, the latter is not possible because the file has no 'bind'. | 16:26.56 |
| ray_laptop | henrys: it would be better if we were interpolating prior to clist to have it emit an image (at full resolution) instead of bunches of small (usually 1x1 pixel) rectangles | 16:26.57 |
| Robin_Watts | 1) Trying to reproduce the problems locally, some of the results are coming out identical for me; can you supply the exact command line you're using please? | 16:27.24 |
| marcosw_ | I'll let the customer know that other than upgrading or fixing their PostScript there isn't a solution. | 16:27.36 |
| Robin_Watts | 2) Some of them aren't identical, and I'm looking at that now. I've got a pcl file here that's doing something odd. | 16:28.00 |
| henrys | ray_laptop:I don't think this is a big deal I'm sure we'll have high level images working interp/rotated by next release. | 16:28.04 |
| marcosw_ | Robin_Watts: sure, I'll email out sample command lines for the various output modes. | 16:28.21 |
| Robin_Watts | henrys: Could I trouble you to help me cut down the PCL file please? | 16:28.34 |
| henrys | Robin_Watts:let me know if you want me to integrate your interplation code. | 16:28.50 |
| | ? | 16:28.53 |
| alexcher | marcosw_: solutions are always possible. They can use a sed script or redefine some ps operators. | 16:28.58 |
| henrys | Robin_Watts:sure just send it to me. | 16:29.11 |
| Robin_Watts | as far as I can tell there is some HPGL stuff at the top, then some bitmap data at the bottom. | 16:29.15 |
| | If I remove the HPGL stuff, it looks fine. | 16:29.23 |
| marcosw_ | alexcher: I was lumping those in to fixing their PostScript. | 16:29.38 |
| Robin_Watts | If I leave it in, I get weird colours from the PCL bitmap data. | 16:29.43 |
| henrys | well hpgl/2 will change the color space. | 16:30.08 |
| Robin_Watts | I think the colors are planar problems. | 16:32.04 |
| | If I understand what's going on, it might be enough to replace the bitmap data in the file with a simple rectangle fill. | 16:36.47 |
| henrys | the gl/2 is setting the raster op | 16:38.17 |
| kens | OK, well I'm off, goodnight everyone. | 16:44.22 |
| henrys | Robin_Watts:what's wrong with the plank output I'm looking at it backwards with the imagemagick bug so I might be missing somethig. | 16:44.29 |
| Robin_Watts | It should be greyscale output, and it looks green to me. | 16:44.48 |
| | Does it not look green to you? (or non-grey at least?) | 16:46.37 |
| henrys | yes it does have colors in the inverted view. | 16:47.27 |
| Robin_Watts | The pamcmyk4 rendering of this is greyscale. | 16:47.51 |
| henrys | indeed so how does your device get colors? | 16:49.45 |
| | it is gray if you pull out the hpgl/2 right? | 16:50.44 |
| Robin_Watts | Yes. | 16:50.53 |
| | I'm getting called with halftoned colors. | 16:51.23 |
| | Essentially copy_color is being called from gz_dc_ht_colored_fill_rectangle | 16:53.52 |
| henrys | I am sure the pamcmyk is being called halftoned as well isn't isn't it hpgl/2 will explictly set an rgb color indexed palette. | 16:58.10 |
| Robin_Watts | Yes, pamcmyk4 is being called halftoned too. | 16:58.45 |
| henrys | so points to planar rop code? | 16:59.20 |
| Robin_Watts | henrys: I was assuming that that was what was at fault, yes, as gs works fine. | 16:59.41 |
| henrys | -ZC will show all the color conversions - might be somewhat useful. | 17:00.03 |
| Robin_Watts | I was hoping to get the file down to a smaller, more managable size. One rectangle fill that goes wrong, for example... | 17:00.34 |
| henrys | oh okay let me try to do that. | 17:01.03 |
| Robin_Watts | Thanks. | 17:01.16 |
| henrys | I suspect you don't do pattern transparency right. if you remove <ESC>*v1O it works. | 17:05.26 |
| Robin_Watts | Pattern transparency. That's pattern masking, really. | 17:06.23 |
| henrys | in pcl pattern transpacy means paint the white pixels - it is limited to the processing of white pixels. | 17:07.31 |
| | *v10 should be opaque white pixels. | 17:08.05 |
| Robin_Watts | I can see a clip device being used here. | 17:09.30 |
| | ok, I can see that pamcmyk4 is getting called with the same colors I am, so I should be able to track it down. | 17:18.11 |
| henrys | good because I've had little luck reducing it. | 17:18.40 |
| | I don't think it happens with just a rectangle. | 17:19.00 |
| | but a combination of raster and pattern. | 17:19.20 |
| Robin_Watts | Thanks for your help. | 17:20.59 |
| | OK, so the strip_copy_rop is used going *into* the pattern accumulator. | 17:39.39 |
| | And I end up with the same thing in the pattern accumulator when it's closed (modulo one being planar and one being chunky) in plank and pamcmyk4. So it must be how the accumulator is then used. | 17:40.25 |
| | Right. It's because we're asking a rop texture device to be made from a planar pattern tile. | 17:56.38 |
| mvrhel2 | ok. this makes no sense to me | 17:58.02 |
| Robin_Watts | "this" in what context ? | 17:58.18 |
| mvrhel2 | why would the assignment at line 1512 have a value of 0x3333 but the assignment at line 1438 have a value of 0xffff in gdevdevn.c | 17:59.01 |
| | sorry | 17:59.03 |
| Robin_Watts | Ah, right. | 17:59.07 |
| mvrhel2 | didnt mean to poke in | 17:59.09 |
| Robin_Watts | no problem. I'm just burbling. | 17:59.22 |
| mvrhel2 | but this is the source of the issue in tiffsep | 17:59.28 |
| | look at that file for me one and those lines | 17:59.36 |
| Robin_Watts | am doing so. | 17:59.51 |
| | gx_color_value solid_color = gx_max_color_value; ? | 18:00.32 |
| mvrhel2 | yes | 18:01.04 |
| | so for some reason at line 1512 solid_color ends up as 0x3333 | 18:01.27 |
| | it should have 0xffff like at line 1438 | 18:01.40 |
| Robin_Watts | gx_max_color_value is a peter-tastic macro. | 18:02.01 |
| mvrhel2 | yes | 18:02.08 |
| Robin_Watts | If the value of gx_color_value_bits changes, then you'll get different results. | 18:02.25 |
| mvrhel2 | ah | 18:02.34 |
| Robin_Watts | Oh, but that's a #define too. | 18:02.55 |
| | 0x3333 is a very strange value for it to be. | 18:03.26 |
| mvrhel2 | yes. I agree | 18:03.33 |
| Robin_Watts | You are looking at a debug build right? </stupid question> | 18:03.54 |
| mvrhel2 | yes | 18:03.59 |
| Robin_Watts | Try adding an: int fred = gx_color_value_bits; before it, recompile, retrace and see if that's changed. | 18:04.35 |
| mvrhel2 | hmm. I just put ((1L << (sizeof(gx_color_value) * 8)) - 1) in my watch window and it came back with 0xffff | 18:06.38 |
| | let me do your suggestion now | 18:06.50 |
| Robin_Watts | mvrhel2: A bit further on solid_color is changed in an interesting way. | 18:07.13 |
| | Are you actually stopped just after that assignment line, or further on ? | 18:07.35 |
| mvrhel2 | yes. I have not reached that yet | 18:07.48 |
| | and we actually do not do that if in this case | 18:07.56 |
| | as solid_not_100 is 0 | 18:08.04 |
| Robin_Watts | Check the disassembly? | 18:08.18 |
| mvrhel2 | gx_color_value solid_color = gx_max_color_value; | 18:08.46 |
| Robin_Watts | Is an assignment actually happening there? or has the compiler delayed that until the scope where solid_color is actually used? | 18:08.46 |
| mvrhel2 | 101C6E82 mov ecx,0FFFFh | 18:08.48 |
| | 101C6E87 mov word ptr [solid_color],cx | 18:08.49 |
| | so it looks like the assignment is correct in the assembly code | 18:09.00 |
| Robin_Watts | Ah, so it could just be the debugger being screwy ? | 18:09.08 |
| mvrhel2 | well the thing is, I watch it later putting value of 0x33 into memory based upon the value | 18:09.43 |
| | at line 1543 | 18:09.58 |
| | it takes solid color. shifts by 8 and assigns | 18:10.20 |
| | to memory out | 18:10.28 |
| | it should be putting ff in to memory | 18:10.46 |
| | not 33 | 18:10.48 |
| Robin_Watts | mvhrel2: dlprintf1("todays insanity forecast=%x\n", solid_color); ? | 18:11.54 |
| mvrhel2 | yes let me do that | 18:12.25 |
| | hmm. it appears that it changed value. it was correct and then a few lines into the code it is not | 18:16.52 |
| Robin_Watts | Step through in dissassembly view. | 18:17.48 |
| | Maybe the caller has in and out on the stack, and they aren't defined to be large enough ? | 18:20.53 |
| | What's the calling routine ? | 18:21.04 |
| mvrhel2 | tiffsep_print_page | 18:22.12 |
| Robin_Watts | ok, scratch that. I'll let you step through and find out where it changes. | 18:22.59 |
| mvrhel2 | ok I am getting close to having this thing cornered | 18:23.30 |
| | oh. | 18:24.56 |
| | crap | 18:24.58 |
| | I see the issue | 18:25.02 |
| | you are correct Robin_Watts | 18:25.51 |
| | during the loop across the line solid color is changed | 18:26.03 |
| Robin_Watts | Of course. But what about this time? :) | 18:26.15 |
| mvrhel2 | and it really needs to be reset | 18:26.33 |
| | ok. gawd. I should have caught that | 18:26.45 |
| | I was starting to think I was going crazy | 18:27.05 |
| Robin_Watts | Oh, sometimes it *does* hit the non-solid case? | 18:27.16 |
| mvrhel2 | well, yes. it is processing a whole line of encoded colors | 18:27.32 |
| | everytime it grabs a new one it really needs to reset solid_color | 18:27.48 |
| | i.e. after line 1522 | 18:27.54 |
| | I find it hard to believe we have not run across this one before | 18:28.21 |
| Robin_Watts | So move the declaration of solid_color into the loop? | 18:28.23 |
| mvrhel2 | yes | 18:29.00 |
| Robin_Watts | We've passed my understanding of what that code does, so I'll bow out :) | 18:29.56 |
| mvrhel2 | thanks for talking me through things | 18:30.23 |
| | ok that fixed it | 18:31.11 |
| | let me test the customers file now | 18:31.16 |
| | ok fixed their file too | 18:33.58 |
| Robin_Watts | Right. | 18:38.34 |
| | tile_colored_fill. | 18:38.37 |
| mvrhel2 | bbiaw | 18:39.48 |
| Robin_Watts | mvrhel2: 2 minuts? | 18:40.17 |
| | 2 minutes before you go? | 18:40.21 |
| mvrhel2 | oh ok | 18:42.20 |
| | you almost missed me. | 18:42.41 |
| Robin_Watts | mvrhel2: I've just been looking at git blame for tile_colored_fill | 18:42.41 |
| | and and in cb54af82 you updated the top part of the if to cope with planar-ness. | 18:43.06 |
| | but didn't change the bottom part. | 18:43.13 |
| mvrhel2 | ok | 18:43.14 |
| Robin_Watts | http://git.ghostscript.com/?p=ghostpdl.git;a=blame;f=gs/base/gxp1fill.c;h=95d824e395dff58e0ae87df1c61eb3bd325f1115;hb=HEAD | 18:43.24 |
| | line 266ish | 18:43.29 |
| | Is that an omission, or was that deliberate? | 18:43.41 |
| | strip_copy_rop always assumes chunky source/texture pixels, currently. | 18:44.48 |
| mvrhel2 | looks like I missede it | 18:44.50 |
| | sorry about that | 18:44.58 |
| Robin_Watts | No worries. | 18:45.02 |
| | The problem is I'm not sure how to actually do this :( | 18:45.13 |
| | But you go, and I'll think about it. | 18:45.20 |
| mvrhel2 | ok. leave me a note if you want me to look at anything | 18:45.58 |
| | bbiaw | 18:46.00 |
| Robin_Watts | I could (further) abuse the lop field, by setting a bit in it to mean 'texture is in planar format'. | 18:59.34 |
| | henrys, ray_laptop, mvrhel2: Any opinions you have on this would be appreciated. | 19:07.23 |
| | When a planar device is in use, we make all pattern buffers planar too. | 19:07.53 |
| | This works fine, except when we come to draw a bitmap in a pattern with a rop. To do that (in the chunky world), the code makes a "rop texture source" device, with the pattern tile as the texture, and then implements copy_color by calling strip_copy_rop. | 19:09.22 |
| | When we try that under the planar world, the pattern tile is in planar format, and so we're in trouble. | 19:09.45 |
| | We can't just call strip_copy_rop on each plane in turn, because we have to do the 'convert to rgb, do the rop, convert back' dance. | 19:10.19 |
| | If I add a new 'lop_t_is_planar' bit, then I can make the planar devices strip_copy_rop implementation fall back to the default one, and in there I can arrange to cope (I think). | 19:12.11 |
| | ray_laptop: See logs. | 19:22.13 |
| henrys | hmm, I guess I don't understand how this is any different than doing say ~D | S where D is the planar framebuffer - how did you solve that? read an entire scanline? I haven't been following was working on something else. | 19:27.20 |
| | more abuse of the notation is fine by me though. | 19:29.31 |
| Robin_Watts | henrys: It's down to the semantics of strip_copy_rop. | 19:32.15 |
| | strip_copy_rop always takes S and T in chunky form. | 19:32.28 |
| | D is read back from the device using getbits (and that copes nicely with the device either being in planar or chunky). | 19:32.53 |
| | The problem here is that in this case T isn't in chunky form. | 19:33.03 |
| henrys | I see. | 19:33.05 |
| Robin_Watts | Looking at the default copy_rop stuff there is code for getting T into the required format by calling a relative of getbits already. | 19:34.40 |
| | The (first) problem is in somehow indicating that T is in planar form, and the lop is the obvious thing to abuse. | 19:35.19 |
| NoSu | Hello Ray | 23:25.54 |
| ray_laptop | hello, NoSu | 23:26.20 |
| | I'll be here a little more (~40 min) then away for about 2 hrs. | 23:27.04 |
| NoSu | Do you happen to have a grasp of pdfwrite & pdfmark to change a pdfs current /CropBox etc? | 23:27.12 |
| | etc being the rest of the boxes as well... | 23:27.35 |
| ray_laptop | NoSu: I saw the logs earlier. I don't think 'pdfmark' can change the CropBox emitted by pdfwrite | 23:27.59 |
| NoSu | is there any way you know of to be able to process it properly? instead of just pending on whats currently there? | 23:29.40 |
| ray_laptop | NoSu: the pdfwrite device doesn't write a CropBox (AFAICT). It _does_ write a "TrimBox" | 23:30.54 |
| NoSu | gs was the closest I have come so far to finding anything related to cropbox manipulation. | 23:31.45 |
| | well when I put that chunk of boxes through pdfmark it pends everything I put there after the current cropbox in the pdf so I know it adds it. | 23:33.19 |
| | as shown here: http://pastebin.com/RCLY3VJ1 | 23:33.57 |
| ray_laptop | NoSu: look at the TrimBox handling in the gdevpdf*.c files. The best thing I can suggest is to add CropBox handling (similar to TrimBox) and then add a "-sReplaceCropBox=[xxx yyy]" parameter. Without code development you "can't get there from here". Ken Sharp (kens) is our expert on pdfwrite behaviour, but the basic (gdevpdf.c) code is pretty easy to adapt. | 23:36.01 |
| | NoSu: the thing about CropBox is that it is a "Root" (Catalog) level dictionary entry and so pdfmark cannot access it. | 23:37.21 |
| NoSu | Ok thanks <henrys> suggested him as well but his timezone doesnt parallel mine so I saw you saying a few words about pdfwrite so was hoping you knew a little of it aswell in the log. | 23:37.44 |
| | so would it be futile to modify the suggested code above or it would be plausible from there? | 23:40.34 |
| ray_laptop | NoSu: sorry -- was on a phone call... | 23:44.54 |
| NoSu | no worries. | 23:45.13 |
| ray_laptop | NoSu: it is NOT futile to modify the code -- that's why GS is OpenSource. If you come up with something that is useful, we _may_ add it to the distribution. If not, keep your "diff" and you can apply it to future releases (usually very easy) | 23:46.39 |
| | NoSu: although I should mention this is the first time in 12+ years that someone asked for this | 23:47.22 |
| | NoSu: and I have to wonder -- what are you _really_ trying to do ? | 23:47.45 |
| NoSu | To batch process 30 pages every night to crop off the colour coding mixes in the boarder of a newspaper to send to a library for storage and use of viewing. | 23:49.26 |
| ray_laptop | NoSu: is all you want to do is to load a PDF, replace a "bad" CropBox with your own and write it out, then please see the toolbin/pdfopt.ps PostScript code that loads and rewrites a PDF. | 23:49.34 |
| | NoSu: this code loads, then re-writes a PDF (using ghostscript, of course) to write a "Linearized" PDF | 23:50.45 |
| NoSu | I will look into this. Theres a few people I see on stackoverflow talking about the same thing one person said to write a bug report about it but I doubt anything ever came of it. | 23:56.24 |
| | Forward 1 day (to 2011/09/28)>>> | |
IRC Logs