| | <<<Back 1 day (to 2012/07/23) | 2012/07/24 |
| cryptopsy | where to find the documentation for BeginPage ? | 00:01.56 |
| | or PageSize | 00:08.20 |
| | can only find mentions of it, but not the parameters they take | 00:08.32 |
| sebras | cryptopsy: have a look at page 428 of postscript language reference 3rd. | 00:15.11 |
| | cryptopsy: it seems as if BeginPage is supplied with an integer operand indicating the number of times showpage has been executed. | 00:15.44 |
| | cryptopsy: and PageSize appears to be described on page 401. | 00:16.29 |
| | N.B. I know next to nothing about postscript. :) | 00:16.49 |
| cryptopsy | page 401 of what? | 00:18.52 |
| | doesn't come up in a google search | 00:19.01 |
| | is that /usr/share/doc stuff? | 00:19.09 |
| ray_work | cryptopsy: The Adobe PostScript Language Reference Manual (I recommend 3rd edition) describes BeginPage etc. | 00:19.57 |
| cryptopsy | yea ... where? | 00:20.14 |
| | not the page number, the location on the internet | 00:20.23 |
| ray_work | Google search "Adobe PLRM" gives as the FIRST hit: http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CGsQFjAA&url=http%3A%2F%2Fwww.adobe.com%2Fproducts%2Fpostscript%2Fpdfs%2FPLRM.pdf&ei=auoNUJWAG9Ou2AWymIGwCw&usg=AFQjCNFc_QpCbSn7Z3jW318KhHbVBrxzuA | 00:21.35 |
| | which leads to: http://www.adobe.com/products/postscript/pdfs/PLRM.pdf | 00:22.33 |
| | cryptopsy: p. 441 says: | 00:24.23 |
| | A procedure to be executed at the beginning of each page. Before calling the procedure, the interpreter initializes the graphics state, erases the current | 00:24.24 |
| | page if appropriate, and pushes an integer on the operand stack indicating how many times showpage has been invoked since the current device was activated. | 00:24.26 |
| | so for the first page, the parameter is "0" | 00:25.07 |
| | cryptopsy: it goes on to say: | 00:26.03 |
| | The PostScript interpreter calls the current deviceâs BeginPage and EndPage procedures, | 00:26.05 |
| | respectively, before beginning and after completing the execution of each page description. With suitable definitions, these procedures can: | 00:26.06 |
| | ⢠Cause multiple virtual pages within a document to be printed on a single physical page (â2-upâ or ân-upâ printing) | 00:26.08 |
| | ⢠Shift the positions of even- and odd-page images differently for binding | 00:26.10 |
| cryptopsy | tnx | 00:26.42 |
| | didnt notice it was an adobe thing | 00:27.07 |
| ray_work | cryptopsy: so to shift pages 1, 3, 5, ... left by 36/72 inch and to shift 2, 4, 6, ... right by 36/72 inch: | 00:27.20 |
| cryptopsy | 441 talks about trapping | 00:30.29 |
| ray_work | use: << /BeginPage { 1 and eq { -36 0 translate } { 36 0 translate } ifelse } >> setpagedevice | 00:30.34 |
| | cryptopsy:it shows as "logical" page 428, offset in the PDF is 441 | 00:31.19 |
| cryptopsy | 441 is trapping | 00:31.30 |
| ray_work | cryptopsy: just search for BeginPage | 00:31.54 |
| cryptopsy | how does that expression read? | 00:32.10 |
| | i don't understand the order notation | 00:32.17 |
| sebras | cryptopsy: it's reverse polish notation. | 00:32.29 |
| ray_work | PS is a stack based (reverse polish) notation system | 00:32.40 |
| cryptopsy | tnx | 00:32.46 |
| sebras | first all the operands, then the operator. | 00:32.51 |
| cryptopsy | yes | 00:32.55 |
| ray_work | so if BeginPage is invoked with 3 on the stack (page 4) 1 and will return 0 | 00:33.23 |
| | oops. | 00:33.26 |
| | I forgot the '0' | 00:33.36 |
| | << /BeginPage { 1 and 0 eq { -36 0 translate } { 36 0 translate } ifelse } >> setpagedevice | 00:33.58 |
| | obviously I didn't try it ;={ | 00:34.10 |
| sebras | ray_work: need to go to bed a few hours ago. good night. | 00:34.11 |
| cryptopsy | do i invoke it one page at a time? | 00:34.11 |
| | ray_work: translate is wrong | 00:34.50 |
| ray_work | cryptopsy: no it stays in effect until overridden (setpagedevice dictionary items are "sticky") | 00:35.02 |
| cryptopsy | it has the same problem as PageOffset, it will put the document outside of the page boundary, thus trimming it | 00:35.16 |
| ray_work | cryptopsy: how is | 00:35.18 |
| | "translate" wrong ? -36 shifts left, 36 shifts right | 00:35.38 |
| cryptopsy | translation operations don't resize by definition | 00:35.40 |
| | i want to _add_ a vertical column, so that i know for sure my text isn't getting cut off | 00:36.08 |
| ray_work | we are back to what we discussed yesterday. This ONLY shifts the image on the page -- nothing else | 00:36.21 |
| cryptopsy | the image on the page can shift outside of the page boundary | 00:36.33 |
| ray_work | OK. so if you want to also reduce the image, then you use 'scale' (before the shift). Do you want to change the aspect ratio or not ? | 00:37.25 |
| cryptopsy | that's wrong too, the printer scales images | 00:37.57 |
| ray_work | and do you know the PageSize or not ? | 00:38.09 |
| cryptopsy | what's the pagesize -- the width of the page? | 00:38.22 |
| | that's A4 paper width | 00:38.36 |
| | the width of the document doesn't matter | 00:38.53 |
| ray_work | cryptopsy: yes, the width. If you want to send data that is scaled down in width to make sure it fits, you need to know the scale factor (i.e. the PageSize) | 00:39.13 |
| cryptopsy | the printer scales it, i dont have to worry about it | 00:39.21 |
| | if i add a 72dpi margin and the printer decides the scale it, it will be smaller/biggr than 72dpi, but it doesn't matter | 00:39.53 |
| ray_work | cryptopsy: are you using N-up printing in a driver or something ? | 00:40.01 |
| cryptopsy | i'm printing double-sided yes | 00:40.11 |
| | that's duplex, but i don't remember what n-up does | 00:40.19 |
| ray_work | or are you going to be stapling/binding A4 pages ? | 00:40.22 |
| cryptopsy | i hope punch and fill injection press glue into the channels | 00:40.44 |
| | hole* | 00:40.47 |
| | there should be a margin so that the book is readable | 00:41.06 |
| | ray_work: i know there's a simple solution to this too, since i had it in my old printing script before i lost it in a disk crash | 00:41.26 |
| | i think i was using x-offset and y-offset | 00:41.36 |
| ray_work | cryptopsy: many drivers or applications automatically apply this if the printer supports Duplex, but if you have a PS or PDF that doesn't know what | 00:42.56 |
| cryptopsy | what? | 00:43.10 |
| ray_work | printer it is going out to, and you need to "fudge" the margins, then BeginPage is your friend | 00:43.28 |
| cryptopsy | i have no idea what you're talking about | 00:43.44 |
| ray_work | cryptopsy: first, are you linux, mac or windoze ? | 00:44.05 |
| | or (heaven forbid) OS/2 or VMS | 00:44.51 |
| | if the pages are created for "normal" PDF viewing as A4 and have no duplex offset (as some PDF's do), then you probably want to keep the Y (vertical) size the same and just scale the X down a bit | 00:46.56 |
| cryptopsy | i'm on shittux yes | 00:47.38 |
| | lets not assume what the pages are created for an _add_ a 1" margin | 00:48.28 |
| ray_work | if the offset you want is "O" then to guarantee that a full bleed image won't get clipped, you need to scale by (595 - O) / 595 | 00:48.45 |
| cryptopsy | translating is like removing a coffin and filling up the hole with water and calling it a swimming pool | 00:48.55 |
| | why 595? | 00:49.59 |
| ray_work | so in PS, to reduce the width by 1 inch and leave the height alone, use: 523 595 div 1 scale | 00:51.46 |
| | 595 is the width of an a4 page | 00:52.00 |
| | or if you prefer /O 72 def % the left and right page offset | 00:52.33 |
| | then: << /BeginPage { 1 and 0 eq { O neg 0 translate } { O 0 translate } ifelse 595 O sub 595 div 1 scale } >> setpagedevice | 00:54.39 |
| | (above also not tested) | 00:54.54 |
| | to generalize it more the BeginPage can get the PageSize width (which is 595 in the above) using: currentpagedevice /PageSize get 1 get | 00:56.19 |
| | which "gets" the second element (offset 1 == width) of the PageSize array currently set | 00:57.00 |
| | cryptopsy: it'll make sense after about the third FULL reading of the PLRM (is that why it's the 3rd edition ???) | 00:58.23 |
| | or playing with 'gs' command line for an hour or so | 00:58.53 |
| | I meant command prompt: GS> | 00:59.18 |
| | where = and == are your friend | 00:59.28 |
| cryptopsy | does 595 change if the page resolution changes? | 01:08.02 |
| | anways, stil need a real solution | 01:08.21 |
| | hey ra | 01:12.05 |
| | ray* | 01:12.07 |
| | ghostscript.com/irclogs/20120723 | 01:12.09 |
| | i found you! | 01:12.11 |
| | i found it in a google search but the URL resolves "not found" | 01:12.49 |
| ray_work | cryptopsy: the PageSize is ALWAYS in 1/72 inch | 01:14.17 |
| | cryptopsy: I am on #ghostscript (where we have irclogs) a lot. | 01:15.11 |
| | cryptopsy: try: http://ghostscript.com/irclogs/2012/07/23.html (that is today) | 01:16.10 |
| | cryptopsy: on unix/linux play with the settings to the default (x11) or on Windows (the display) device and you can see the pages before wasting paper | 01:18.04 |
| | you can put the setpagedevice script into a prefix .ps file or into a command line -c "..." sequence before -f | 01:19.34 |
| | I have to go eat dinner -- I'll check back in a bit. | 01:20.23 |
| cryptopsy | ray_work: that fraction should be (595+'O')/595 | 03:44.13 |
| mvrhel | ok narrowed this thing down to an path filled with an image where the color space is the DeviceN color space with 17 colorants | 04:57.12 |
| | there is def. something going on at the interpreter level in some sense. setdevicenspace is not even called depending upon GS_CLIENT_COLOR_MAX_COMPONENTS and we get complaints about q and Q errors based on this | 05:09.33 |
| | oh it has to be as Robin_Watts said in icremap.h | 05:10.26 |
| | and yes that is it | 05:11.08 |
| | henrys: so I would like to talk about 693185 a bit tomorrow at the meeting | 05:26.44 |
| cryptopsy | desperately need a way to add a margin | 06:04.03 |
| | ray_work: i think i go tit | 06:31.42 |
| | got it | 06:31.44 |
| | HWmargins can do what i want | 06:31.52 |
| | none of the methods are reliable though, the book i have is a scan, so the proportions are A4 proportions, but since its a scan the widths and height are so large, margins of 72 aren't one inch, but only a fraction of an inch | 06:32.35 |
| | i am wrong, this has the same effect as -offset | 06:37.54 |
| | or .. | 06:38.01 |
| | it can be used in combination with Margins | 06:38.33 |
| | nope | 06:45.03 |
| ray_laptop | Robin_Watts: I don't understand the results from your clusterpush -- it seems this was from the colors_use to color_usage change, but I don't understand the differences, and the performance difference (since it seems faster) | 06:50.39 |
| cryptopsy | HwMargins accepts negative values, which doesn't do anything , maybe this shouldn't be permitted? | 06:50.48 |
| kens | cryptopsy there are lots of places in PostScript where you can supply silly values that don't trigger errors | 06:51.33 |
| ray_laptop | cryptopsy: why -- ghostscript is designed to meet the spec and to match Adobe PostScript | 06:51.43 |
| kens | Just because its daft doesn't mean its illegal | 06:51.48 |
| ray_laptop | thanks, kens | 06:51.55 |
| | I need to catch up on the logs ... | 06:52.10 |
| kens | Me too, even more so :-) | 06:52.18 |
| cryptopsy | kens: waste of time waiting for a job that doesn't change anything | 06:52.26 |
| kens | cryptopsy, welcome to the world of computers | 06:52.48 |
| | garbage in garbage out | 06:52.53 |
| cryptopsy | this is not the case of that | 06:53.00 |
| | it is the case of cryptic error codes | 06:53.17 |
| ray_laptop | cryptopsy: if you have a scan, then you _might_ be able to trust the CropBox | 06:53.18 |
| cryptopsy | why is it so damn hard to add a margin? | 06:53.39 |
| kens | cryptopsy all PostSc ript errors are cryptic, and you said that this simply had no effect, you didn't say it caused an error | 06:53.41 |
| cryptopsy | kens: yea ... it doesn't cause an error | 06:53.56 |
| ray_laptop | but there is no strict requirement that a PDF creator sets the CropBox to a real size | 06:53.59 |
| cryptopsy | but you said 'world of computing' | 06:54.00 |
| | the unix pestillence and all associated tech | 06:54.18 |
| | like C, LaTeX, PERL | 06:54.23 |
| kens | Yes, things don't always do what you expect | 06:54.25 |
| cryptopsy | XML | 06:54.27 |
| | is it rare thing don't do what you espect with regularity, with total disregard for the user | 06:54.52 |
| kens | And ncomputers are dumb, they'll do *exactly* what you tell them, even if its stupid | 06:54.53 |
| | Mind you, I know people like thart too :-) | 06:55.06 |
| cryptopsy | that's not true either | 06:55.09 |
| kens | Yes it is | 06:55.20 |
| cryptopsy | no, it isn't | 06:55.24 |
| kens | Yes it is | 06:55.27 |
| | Computers can't do anything except what they are told | 06:55.47 |
| ray_laptop | cryptopsy: IFF you know the CropBox is trustworthy, then (and only then) you can do a BeginPage offset (translate) without a scale if the right and left edge of the CropBox are what you need for readability | 06:56.09 |
| cryptopsy | this is the difference between the stupid tech geeking dumbasses and a computer scientist, where the tech geek will use the phrase 'computers are dumb' barn-yard slang where there is appropriate terminology like 'finite state' 'deterministic' 'chaotic' to explain the behavior | 06:56.28 |
| kens | Ah, you're a computer scientist ? | 06:56.50 |
| | And if you'd like to show me a computer that isn't dumb I'd be interested | 06:57.10 |
| ray_laptop | cryptopsy: you can get the CropBox limits for all pages in a document quickly using the runpdfbegin etc. gs operators | 06:57.14 |
| cryptopsy | actually by training i'm a biophysicist | 06:57.16 |
| | at the graduate level | 06:57.22 |
| | computers can't be dumb, people can be dumb | 06:57.35 |
| | not calling you dumb | 06:57.43 |
| kens | Computers are clearly dumb, just like rocks | 06:57.44 |
| ray_laptop | cryptopsy: psych major I presume ? | 06:57.46 |
| cryptopsy | ray_laptop: what? | 06:57.55 |
| | majors are )_under_(graduate | 06:58.17 |
| ray_laptop | cryptopsy: we have no bias against "other" scientists -- one of our guys is getting his PhD in bio-technology (or something like that), but he was a software guy for 15+ years before jumping ship | 07:00.12 |
| cryptopsy | 15 years of programming doesn't give you superiority over an expert in mathematics | 07:00.48 |
| ray_laptop | mathmeticians are the worst ;-) | 07:01.24 |
| kens | cyrptopsy, it does as far as programming is concerned, and I nevver claimed that anyway, *and* I'm a mathematician to a decent level too | 07:01.26 |
| cryptopsy | uh, however biophysics is practically a programming topic | 07:01.29 |
| | i wonder what the great mathematicians of this century have to say about the computing industry | 07:02.01 |
| | would dijkstra approve? | 07:02.11 |
| ray_laptop | cryptopsy: we don't want to get all puffed up here -- just try the things we suggest -- please | 07:02.28 |
| cryptopsy | that didn't even make sense | 07:02.51 |
| ray_laptop | that's all we nned OO mathmetics :-/ | 07:03.04 |
| cryptopsy | i've been here all day for two days and i was argueing error reporting | 07:03.15 |
| | trying all the things suggested | 07:03.22 |
| | the two are unrelated though | 07:03.31 |
| ray_laptop | cryptopsy: you are trying to get documents out with even and odd pages with different placement on a page, right ? | 07:03.52 |
| cryptopsy | sure | 07:03.59 |
| ray_laptop | cryptopsy: so have you tried the BeginPage proc that I put on IRC ??? | 07:04.21 |
| cryptopsy | es | 07:04.24 |
| | we ended up having to resize and calculate widths | 07:04.33 |
| ray_laptop | and the results were ??? | 07:04.39 |
| cryptopsy | unreliability for the reasons mentioned above | 07:04.53 |
| ray_laptop | cryptopsy: and why did you have to resize ? did the input pages not fit on the result pages when they were offset +/- .5 inch on left and right pages (even and odd) ? | 07:05.53 |
| | (or whatever offset amount you need to provide for your binding) | 07:07.01 |
| cryptopsy | ray_laptop: to accomodate the margins so that the file doesn't get concacenate during translation | 07:07.25 |
| | there's a perl script pdfcrop that can do it easily | 07:07.47 |
| | add margins | 07:07.57 |
| ray_laptop | huh ?? I assume that is a partial sentence | 07:08.05 |
| cryptopsy | 07:03:07 < ray_laptop> cryptopsy: and why did you have to resize ? | 07:08.21 |
| | 07:04:38 < cryptopsy> ray_laptop: to accomodate the margins so that the file doesn't get concacenate during translation | 07:08.25 |
| ray_laptop | concatenate doesn't make sense, nor does translation | 07:09.18 |
| | cryptopsy: I thought the problem was clipping | 07:09.40 |
| cryptopsy | yes | 07:10.26 |
| | that's the problem | 07:10.29 |
| ray_laptop | if the area that the 'scan' imaged didn't fit in the a4 page width when reduced by 1 inch | 07:10.30 |
| cryptopsy | it's getting cut off | 07:10.38 |
| ray_laptop | cryptopsy: we call that clipping | 07:10.50 |
| cryptopsy | too many tech geek jargon to remember | 07:11.07 |
| ray_laptop | the only way to avoid clipping is to scale | 07:11.09 |
| cryptopsy | gs don't have to be the one to scale, the printer do it fine | 07:11.26 |
| | for example, pdf->photo->pdf allow to easily use imagemagick to add the margin | 07:11.49 |
| ray_laptop | you can scale in width only, or in both width and height (which is called "preserve aspect ratio" by some) | 07:11.54 |
| cryptopsy | kens: http://xahlee.info/UnixResource_dir/writ/bitmask.html | 07:12.06 |
| kens | apropos of what ? | 07:12.30 |
| cryptopsy | bitmask hack for error codes | 07:12.40 |
| kens | yes, and ? | 07:12.45 |
| cryptopsy | you should be aware where you stand on the criminality scale with your error reporting attitude | 07:12.59 |
| kens | cryptopsy, you really are becoming offensive | 07:13.13 |
| ray_laptop | cryptopsy: as I said several days ago, -dPDFitPage will scale and center input pages to the output page. Coupled with BeginPage, you can offset even and odd pages | 07:13.19 |
| kens | Apart from anything else you don't know what my attitude is to error reporting | 07:13.37 |
| cryptopsy | ray_laptop: it is still not reliable in cases, whereas simply add a margin is reliable | 07:13.43 |
| ray_laptop | -dUseCropBox will let you fit the CropBox size to the resulting page instead of the default MediaSize | 07:14.09 |
| cryptopsy | how i that useful? | 07:14.52 |
| | i* | 07:14.53 |
| | is* | 07:14.55 |
| ray_laptop | cryptopsy: "simply" adding a margin (and reducing the input page size to avoid clipping) is something I already gave you | 07:15.37 |
| marcosw1 | kens: I can ask you a couple of questions about the email you replied to asking about file sizes with pswrite? | 07:16.19 |
| ray_laptop | cryptopsy: it is a sequence of a translate, then a scale | 07:16.24 |
| kens | marcosw1 sure go ahead | 07:16.31 |
| | surprised to see you and ray still up and about | 07:16.44 |
| ray_laptop | marcosw: please -- we need an interruption' | 07:16.45 |
| marcosw1 | you said: Applying JPEG to data which has previously been JPEG processed results in unpleasant artifacts, so lossless compression is used | 07:16.59 |
| kens | Yes | 07:17.07 |
| | The original PDF file ahs a JPEG2000 compressed image, which we decompress | 07:17.24 |
| marcosw1 | the artifacts portion is clearly true, but does ps2write really look at the input stream and decide to not jpeg compress streams that were previously jpeg compressed? | 07:17.47 |
| kens | If we were to recompress that (for a smaller file size) we would get nasty artefacts in the output due to the re-application of the low pass and high pass filters | 07:17.55 |
| ray_laptop | kens: it is ? I thought we didin't detect the input filter type, but instead looked for image characteristics (sharp edges) | 07:18.01 |
| kens | marcosw1 no in truth it always writes images with losszless compression (ps2write) | 07:18.18 |
| | THis is something I was discussing wirth chrisl the other day | 07:18.30 |
| | And needs to change | 07:18.35 |
| ray_laptop | kens: do we have a way (that I wasn't aware of) to detect input filter type ? | 07:18.39 |
| kens | ray_laptop : no, but we need one. | 07:18.46 |
| | I did some work on looking at reapplying JPEG with exactly the same parameters, to see if it would cause the same kind of problems | 07:19.31 |
| | But it would be better to get hold of the original image stream | 07:19.43 |
| cryptopsy | 06:53:23 < ray_laptop> cryptopsy: IFF you know the CropBox is trustworthy, then (and only then) | 07:19.48 |
| ray_laptop | kens: I agree (one of the few areas I agreed with Igor) -- but we needed a way to get the input data (JPEG) so we could pass it through without decompressing/recomressing | 07:19.53 |
| | kens: what you just said :-) | 07:20.09 |
| kens | :-) | 07:20.15 |
| marcosw1 | so if the user was willing to live with the jpeg recompression artifacts is there a command line option to force jpeg compression? Also can they use the ASCII85EncodePages option to write out binary files? | 07:20.33 |
| kens | marcos1 my opint was, really, that we couldn't do lossy compression because it would look bad, even if we could, which we can't | 07:20.43 |
| | marcosw1 it probably got lost in the confusion there, but no thre is currently no way to use lossy compression, we *always* use lossless for ps2write | 07:21.20 |
| ray_laptop | marcosw: AFAIK, if the input is JPEG, then it will be "smooth enough" to use JPEG on output -- we run two filters in parallel | 07:21.30 |
| kens | It should be possible to get the file as binary though | 07:21.44 |
| ray_laptop | kens: really ? | 07:21.48 |
| kens | ray_laptop : the device needs to support binary output which is a flag in the ps21write/pdfwrite device somewhere | 07:22.23 |
| ray_laptop | since ps2 allows JPEG (DCTDecode) why don't we do the automatic detection of "best' | 07:22.36 |
| kens | ray_laptop : all images in ps2write are 'inline' | 07:22.57 |
| ray_laptop | JPEG doesn't imply binary | 07:23.01 |
| kens | pdfwrite writes inline images with lossless compression | 07:23.09 |
| | ps2write inherits this attitude | 07:23.21 |
| marcosw1 | kens: yeah, your reply really sounded like lossy compression was not available just because the input was already jpeg compressed. | 07:23.52 |
| kens | marcosw1 sorry, that wasn't quite what I meant | 07:24.08 |
| ray_laptop | I don't know why ps2write doesn't treat image data the same as font data (that can be pseudo objects that can be sent "in order) | 07:24.23 |
| kens | What I mean is that its not possible to do it at all in ps2write at the moment, and even if it were the results might well be unacceptable | 07:24.30 |
| | ray_laptop : because its really pdfwrite under the hood | 07:24.42 |
| ray_laptop | the results wouldn't be any worse that what we get from pdfwrite | 07:25.03 |
| kens | In order to get images in the right order we have to treat them as 'inline' otherwise we don't get them in the content stream | 07:25.25 |
| | THey are imaghe XObjects if they are not inline | 07:25.43 |
| marcosw1 | ken: so basically the customer is screwed, one of his files is a large image which doesn't compress well lossleslly (sp?) and the other file uses transparency also generates a large, uncompressable image. | 07:25.51 |
| ray_laptop | kens: how do we get font data in the right order ? | 07:26.03 |
| kens | Yes, that's pretty much it marcosw1 | 07:26.03 |
| marcosw1 | thanks, I think :-) | 07:26.13 |
| kens | ray_laptop : we take care to emit resources forst | 07:26.17 |
| | But as I was in the middle fo saying. | 07:26.30 |
| ray_laptop | marcosw: a limitation that exists now -- not a fundamental issue | 07:26.40 |
| kens | Dealing with large images out of the page data is difficult in level 3 and extremely so in level 2 (no reusablestreamdecode) | 07:26.56 |
| | We can define fonts up front and let them persist since tehy are usually relatively small | 07:27.16 |
| | a few 10's of Kb, whereas images can be many megabytes | 07:27.31 |
| ray_laptop | kens: such as Japanese CID fonts ? | 07:27.52 |
| kens | ray_laptop : we subset fonts, so they are smaller anyway | 07:28.02 |
| | and we can't emit CIDFonts anyway, so we emit multiple type 1 fonts | 07:28.14 |
| ray_laptop | OK. point taken | 07:28.31 |
| kens | I'm not saying its ideal, but given the nature of ps2write, its what we can do | 07:28.57 |
| | If it were me I would rewrite ps2write competely, its horrible | 07:29.11 |
| marcosw1 | kens: "it's horrible" describes much of the code :-) | 07:29.36 |
| kens | I was about to say I'd rewrite pdfwrite too given a year or two to get it right, but that's never going to happen | 07:30.01 |
| ray_laptop | for large source data images, we _could_ handle it without a complete re-write (I think) -- we talked about this for "streamable PDF" before you came on board | 07:30.38 |
| kens | Hmm, OK.... :-) | 07:30.53 |
| | But inline images are perfectly acceptable really | 07:31.06 |
| | and much more the PostScript idiom | 07:31.17 |
| ray_laptop | except that we don't do JPEG compression | 07:31.31 |
| kens | Its just our current treatment of them which needs improvement | 07:31.35 |
| | ray_laptop : I don't believe we do downsampling either..... | 07:31.53 |
| | Being inline we bypass a lot of stuff | 07:32.17 |
| ray_laptop | can inline images support JPEG ? (note that when doing ps2write we don't really have to emit perfect PDF) | 07:32.21 |
| kens | ray_laptop : at themoment, no, in fuiture I don't see why not | 07:32.42 |
| | At worst we would need a new 'asides' temporary file | 07:32.58 |
| | But I see no reason why we cna't just put the DCT compressed data straight into the file, its a filter just like LZW which is what we use now | 07:33.32 |
| ray_laptop | kens: OK. so we are discussing a localized minor issue -- JPEG for inline images when the output is ps2write ? | 07:33.36 |
| kens | ray_laptop : Sort of | 07:33.47 |
| ray_laptop | not a complete re-write of pdfwrite | 07:33.56 |
| kens | Oh no, a complete rewrite of pdfwrite is just something I think woudl be a good idea ;-) | 07:34.13 |
| | We could do the filters thing, just that we don't | 07:34.29 |
| | The worry is always that recompressing DCT (or wavelet) filtered components with DCT or wa velet comression will give rise to visual errors | 07:35.18 |
| ray_laptop | kens: well, maybe. IMHO, we'd end up taking into account just as many special issues as we do now (since we are on the back end of the device API interface) | 07:35.21 |
| kens | Due to re-applying high and low pass filters to the same data | 07:35.28 |
| ray_laptop | kens: I totally agree about de-re compression passes | 07:35.45 |
| kens | ray_laptop : yes, but the code we have is terrible | 07:35.47 |
| | The special cases I object to less than the unreadable and un-maintainable spaghetti we currently have | 07:36.58 |
| ray_laptop | kens: the code we have did sort of 'evolve' as the PDF spec, and knowledge of what worked with various evolving versions of Acrobat Reader emerged. | 07:37.06 |
| kens | But realistically we can't rewrite it | 07:37.14 |
| | ray_laptop : yes, and at 5D we did rewrite teh PDF otuptu code totally, at least in part because of that | 07:37.38 |
| | Mind you, I didn't personally liek the style that was used, but at least it was consistent | 07:38.03 |
| ray_laptop | kens: not sure that it won't ever happen. the mupdf pdf writing is a decent starting point (if not as generalized) | 07:38.23 |
| kens | ray_laptop : but that doesn't use the same API, or does it ? | 07:38.46 |
| | So it wouldn't work with PCL input for example | 07:38.56 |
| | marcosw1 thanks for re-writing the customer mail, nicely put | 07:39.53 |
| ray_laptop | mupdf doesn't use the same API, but it is pdf/xps centric | 07:40.18 |
| | IMHO, PCL->PDF should be image PDF only | 07:40.45 |
| kens | ray_laptop : yes, that's kind of what I mean, as long as we support PS, PCL and XPS, we will need something like pdfwrite to emit PDF from those languages | 07:40.47 |
| | ray_laptop : Not disagreeing, but its not what people want | 07:41.03 |
| | No matter how many times I say 'but it won't work perfectly' | 07:41.21 |
| ray_laptop | kens: but how much do those folks pay -- let them bother someone else | 07:41.37 |
| kens | ray_laptop : that one's above my pay grade :-) | 07:41.54 |
| | The ability to detect the actual use of ROPS and render when used would be nice | 07:42.28 |
| | But probably means using a display list of some sort | 07:42.43 |
| ray_laptop | kens: well as long as we do as bad a job as possible of PCL->PDF then we can get rid of those customer | 07:42.58 |
| kens | If only that were true :-( | 07:43.14 |
| ray_laptop | kens: the clist code keeps track of non-idempotent ROPs but unfortunately fonts are just bitmaps in the clist | 07:44.11 |
| kens | Well we could maintain the fonts ourselves pre clist | 07:44.31 |
| | I assume we cna have a device pre clist ? | 07:44.41 |
| ray_laptop | we need to task henrys with writing a pre-scanner (on a page by page basis) for PCL that detects the usage of non-idempotent ROPs :-) | 07:45.30 |
| kens | Yeah, but won't work for streamed input ? | 07:45.53 |
| ray_laptop | sort of like PDF does to collect "page_uses_transparency" | 07:45.59 |
| kens | WOuld be nice, but probably not feasible | 07:46.12 |
| ray_laptop | a tempfile for streamed input is easy | 07:46.13 |
| kens | That's what I was thinking | 07:46.22 |
| | How big do PCL files get ? | 07:46.29 |
| | Mind you, if they are doing PDF copnversion tehy need a disk anwyway | 07:46.42 |
| | SO that's a ridoculous argument, ignore me | 07:46.53 |
| ray_laptop | check norbert's PCL performance files -- some are > 80 Mb | 07:47.06 |
| kens | A mere trifle compared to PDF and PostScript | 07:47.23 |
| ray_laptop | iirce | 07:47.23 |
| | converting to PDF _does_ require disk and tempfile, right | 07:48.01 |
| kens | I guess it is a possibility we could think of when doign PDF output only | 07:48.05 |
| chrisl | pdfwrite already has a horrible influence on the interpreter, having *that* extent of influence is a horrific idea! | 07:48.22 |
| kens | Yes, PDF and PS outptu require a disk, or at least a seekable stream, which is the same thing for practical purposes | 07:48.31 |
| ray_laptop | chrisl is an idealist | 07:48.58 |
| | time for me to do the dishes and go to sleep ... | 07:49.20 |
| kens | Yeah, definitely goodnight ray_laptop | 07:49.30 |
| chrisl | I really don't think an *output* device should cause significant differences in the bevahiour of the interpeter! | 07:49.44 |
| ray_laptop | g'nite, kens (and chrisl) | 07:49.50 |
| chrisl | g'nite Ray! | 07:49.57 |
| kens | chrisl I'd like to agree, but it would be nice to be able to handle ROPS 'better' | 07:50.12 |
| ray_laptop | chrisl: not the interpreter -- just the type of output -- high level or image | 07:50.21 |
| kens | Rendering when required would be a useful feature | 07:50.38 |
| cryptopsy | apparently 'add margin' is different from 'add extra margin' to the tech geeks, and cups' ps tool can do it easily | 07:50.41 |
| chrisl | ray_laptop: the suggestion was for the interpreter to pre-scan the input for pdfwrite..... | 07:50.52 |
| ray_laptop | not a lot different from deciding to do Type 3 fonts as bitmaps | 07:50.57 |
| cryptopsy | i remember the site i got the code from a year ago when i was in here asking the same question | 07:50.58 |
| | what the hell, ghostscript? | 07:51.06 |
| chrisl | kens: I guess I don't see why the ROPS handling couldn't be done with a clist implementation..... | 07:51.36 |
| kens | chrisl I think it could be done. | 07:51.51 |
| ray_laptop | chrisl: true -- that is somewhat invasive | 07:51.51 |
| kens | ray's point was that fonts aren't fonts any more post clist | 07:52.06 |
| | And if we are *not* rendering to a bitmap, we want the fonts. | 07:52.20 |
| ray_laptop | chrisl: the gotcha is getting text into the clist so that pdfwrite can spit it out as text -- images and graphics are OK | 07:52.48 |
| chrisl | There are lots of things that normally disappear in the graphics library that pdfwrite has to get hold of by some means...... | 07:52.54 |
| cryptopsy | By default, pages larger than the paper are shrunk to fit. | 07:52.55 |
| | thank god | 07:53.00 |
| kens | chrisl, yes, but we don't normally *have* a clist with pdfwrite | 07:53.15 |
| | Which allows it to extend tentacles back deep into the front end | 07:53.54 |
| ray_laptop | cryptopsy: not true -- that depends on the PageSize Policy setting. The default is to clip input larger than the page to whatever fits | 07:53.58 |
| chrisl | kens: but as you mentioned, it should be viable to have a pre-clist forwarding device which would collect the stuff we need to survive the clist | 07:54.04 |
| kens | chrisl, yes, that was what I was thining. | 07:54.17 |
| cryptopsy | ray_laptop: its from the pdftops manpage | 07:54.34 |
| kens | I suspect that (for PCL) fonts are the only thing we would have to worry about | 07:54.36 |
| ray_laptop | kens: chrisl: that's sort of what the 'fitz' display list (mupdf) is | 07:54.54 |
| | a really high level display list -- keeps fonts, images, etc. | 07:55.21 |
| kens | Anyway, as usual its a case of 'if we really want to we can do this' | 07:55.41 |
| | But its a lot of effort, so we won't unless someone important rpesses hard, or someone pays us ;-) | 07:56.02 |
| ray_laptop | cryptopsy: go bother the xpdf people -- pdftops is xpdf based | 07:56.34 |
| | cryptopsy: read the Policies section of the setpagedevice documentation in the PLRM | 07:58.23 |
| | g'nite all | 07:59.21 |
| kens | bye ray_laptop | 07:59.30 |
| sebras | good morning Mr. Watts! | 09:01.39 |
| Robin_Watts | morning | 09:11.38 |
| sebras | tor8: hiya! | 09:12.35 |
| sebras | has a lazy day at work... ;) | 09:12.42 |
| tor8 | morning | 09:15.18 |
| | sebras: just pushed your function patches | 09:15.33 |
| sebras | tor8: you mentioned a potential problem with exponential functions..? was is benign? | 09:22.52 |
| | tor8: or is there something for me to fix? | 09:23.02 |
| tor8 | sebras: looking into it now, but it looks like *all* exp funs print too few/many warnings and the resulting pdf differs, and not in a good way | 09:23.39 |
| sebras | tor8: ouch. unless anyone has pulled do revert the entire stack and I'll take a look at it tonight. | 09:24.16 |
| | tor8: I'm surprised that I haven't seen this though. | 09:24.31 |
| tor8 | you divide by two where you shouldn't! | 09:24.51 |
| sebras | I do? d'oh. if you don't mind you're welcome to fix it of course. | 09:25.14 |
| tor8 | I'll fix it | 09:27.00 |
| kens | Oh oh, MuPDF commit spam ;-) | 09:28.16 |
| sebras | excellent. | 09:28.16 |
| | kens: sorry. :) | 09:28.24 |
| tor8 | sebras: fixed and force pushed | 09:53.32 |
| sebras | tor8: thanks. | 09:55.10 |
| cryptopsy | is pdf2ps deprecated? | 10:09.45 |
| gnagno | hello all | 10:16.12 |
| | is it possibile that a pdf page is composed both by character gliphs and text? | 10:17.00 |
| kens | text *is* character glyphs | 10:18.27 |
| | I'm not sure what your question is ? | 10:18.41 |
| gnagno | kens, sorry... maybe I didn't explain myself correctly | 10:18.45 |
| kens | No problem | 10:18.52 |
| gnagno | I mean, for the purpose or reducing as much as possibile the size of the file I would like to have only the minimum information required in my file | 10:19.23 |
| kens | OK | 10:19.28 |
| cryptopsy | he wants ocr | 10:19.35 |
| kens | So you wnat your text to be glyphs from fonts | 10:19.38 |
| | Not images, or bitmaps | 10:19.52 |
| | THat's teh most compact representation for text in a PDF file | 10:20.03 |
| gnagno | but at the same time I would like my text to be zoomable with no quality loss | 10:20.05 |
| kens | Sure, as long as you are using vector fonts (not bitmapped fonts) that will come for free | 10:20.28 |
| gnagno | how can I achieve this compact rapresentation with ghostscript ? | 10:20.29 |
| kens | Ah, that depends on what your input is | 10:20.37 |
| | Ghostscript (technically the pdfwrite device) puts in the PDF file the best representation it can of what cam on the input | 10:21.01 |
| | So the input needs to have the text decribed as fonts as well | 10:21.11 |
| | Am I making sense gnagno ? | 10:21.42 |
| gnagno | kens, yes... I am slowing understanding this.... I am starting to work with pdfs this days :) | 10:22.13 |
| kens | Its a lot to learn | 10:22.26 |
| cryptopsy | there lot of tool for compressing pdf | 10:22.27 |
| kens | gnagno : do you know what the input contains ? | 10:22.43 |
| gnagno | kens, basically newspapers | 10:23.01 |
| kens | Hmmm | 10:23.08 |
| | Are the newspaper scanned or are they the original electronic page layout ? | 10:23.23 |
| gnagno | they are the original electronic layouts | 10:23.35 |
| | do you want I send you some examples? | 10:23.43 |
| kens | An example would be excellent | 10:23.57 |
| gnagno | how can I send you? | 10:24.09 |
| kens | If you can out it on a public URL that's fine, or send email to ken.sharp at artifex.com | 10:24.31 |
| | obviously at is '@' | 10:24.44 |
| gnagno | I will put them in a public url, I don't want to fill your mailbox :) | 10:25.56 |
| kens | wNP | 10:26.20 |
| gnagno | kens, I will send you different examples of pages, this is oen: http://176.34.96.234:8080/pdf/out001.pdf | 10:29.32 |
| kens | So you are starting form a PDF file ? | 10:29.54 |
| gnagno | this page was extracted from the same newspaper, but as you can see it's a lot bigger: http://176.34.96.234:8080/pdf/out010.pdf | 10:30.01 |
| | kens, yes, I receive a pdf file and split it using gs | 10:30.11 |
| | do you want to see the full original file ? | 10:30.18 |
| kens | Maybe. THese files were produced by GS ? | 10:30.33 |
| gnagno | yes | 10:30.40 |
| kens | The headline is bitmapped and ugly | 10:30.41 |
| gnagno | the headline is not very important | 10:31.27 |
| | I care more about the text | 10:31.36 |
| kens | Hmm, I cna't seem to save hese files from Firefox or IE | 10:31.49 |
| | AH, now I can | 10:32.06 |
| | OK so I'm not sure what you want form this. | 10:32.56 |
| | The text is already expressed in fonts | 10:33.07 |
| | So its probably as compact as its likely to get | 10:33.15 |
| | Let me just look at this with a diferetn version of Acrobat | 10:33.37 |
| | OK according to this, teh fonts are 32k, images are 40k and the bulk of the file is the contents at 195k | 10:35.18 |
| | I'm not sure there is a lot of scope for reducing that | 10:35.48 |
| | Did you have a particular goal in mind gnagno ? A specific file size ? | 10:36.41 |
| | Agh, the second file is larger | 10:37.11 |
| gnagno | sorry back | 10:37.21 |
| kens | No problem | 10:37.28 |
| gnagno | yes... the first file is not problematic | 10:37.39 |
| | the second one is very problematic | 10:37.45 |
| kens | ah :) | 10:37.45 |
| gnagno | they where extracted from the same source | 10:37.52 |
| | with the same command | 10:37.55 |
| kens | OK let me analyse the second file | 10:38.07 |
| | Hmm | 10:38.12 |
| | The content streams are surprisingly large at 1.2MB | 10:38.24 |
| | Fonts are only 24k | 10:38.33 |
| gnagno | I used this command for splitting the file: gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook -dNOPAUSE -dQUIET -dBATCH -dUseCropBox=true -dUseCIEColor -sOutputFile=out%03d.pdf in.pdf | 10:38.35 |
| kens | and images 100k | 10:38.39 |
| | I wouldn't set UseCIEColor | 10:38.53 |
| | Or PDFSETTINGS at all | 10:39.02 |
| | Part of the problem look slike its some of the images. They are not drawn as one single image but lots of smaller ones | 10:39.48 |
| | So thre's quite a bit of overhead in teh setup for each one | 10:39.58 |
| gnagno | is it possible to unify them in one image somehow? | 10:40.17 |
| kens | Not currently | 10:40.39 |
| | I would guess hte oroginal ghad the same layout | 10:40.56 |
| cryptopsy | does gs support jpeg2000 encoding or is it still encumbered by patents? | 10:41.00 |
| gnagno | kens how can you get those infos ? | 10:41.22 |
| kens | gnagno : I can decode and read teh PDF file | 10:41.33 |
| gnagno | kens, using gs ? | 10:41.41 |
| kens | gnagno : no, a combination of tools | 10:41.59 |
| | Plus knowing how to read the PDF page description | 10:42.14 |
| gnagno | kens, how can I get this know how? looks like you're reading the pdf code like in matrix to me :) | 10:42.41 |
| kens | But giove me another minute, I'm still looking | 10:42.42 |
| gnagno | ok thanks for your time | 10:42.48 |
| cryptopsy | trying to do pdf-->lossless image | 10:43.00 |
| kens | gnagno : I've been working with PDF for a liong time, after a while you get so you can read the decompressed files :( | 10:43.08 |
| | wow, decompressed that second page is 18Mb | 10:43.35 |
| gnagno | it's not so small | 10:44.37 |
| kens | gnagno : the second page loks like much of the text has been converted into vectors | 10:44.46 |
| | Probably by someone importing an EPS from Illustrator or something like that | 10:45.05 |
| | Unfrotunately thre is no way for us to 'undo' that operation | 10:45.18 |
| gnagno | so the problem is at the root of the process ? | 10:46.12 |
| kens | I'm afraid it looks that way | 10:46.22 |
| | The text has been converted into a series of lines and curves and fills before we see it | 10:46.36 |
| | Almost the entirety of the page description is 'move' 'line' 'curve' and either fill or stroke | 10:47.17 |
| gnagno | kens I have a page that is almost 20mb.... I think that is even worse | 10:47.52 |
| kens | My guess is that someone did a lot of the work in an application like Adobe Illustartor (or possibly InDesign) and used the option to convert text to outlines | 10:47.57 |
| | gnagno : not all the text on this page is liek this, so its easy to imagine a worse example | 10:48.16 |
| | TO 'fix' this you would probably have to go back to the original source documents and recreate teh whole page layout without selecting that option. | 10:49.07 |
| | Which is undoubtedly too much work | 10:49.14 |
| gnagno | which I can't do... because this is how I receive the pdf.... I should have a contact with the editor :) | 10:49.41 |
| kens | Another option woudl be to use some kind of Optical Character Recognition engine to convert the linwework into text | 10:49.50 |
| gnagno | kens, is this solution reliable ? | 10:50.18 |
| kens | gnagno : I am told that OCR is highly reliable these days, but I am not an expert in this field | 10:50.36 |
| gnagno | thank you for all your help and your time kens I will spend some time studying the topic now | 10:53.34 |
| | can you please reccomend me some sources for study? | 10:53.46 |
| kens | gnagno : for OCR ? I'm sorry I can't really its been a very long time since I studied the subject | 10:55.26 |
| gnagno | kens, no for studying the pdf topic in general | 11:01.05 |
| kens | Oh well the best is the PDF reference manual | 11:01.17 |
| | Everything is in there | 11:01.41 |
| | FOr tools you cna look at MuPDF (also from us) pdftk and probably many others | 11:01.55 |
| gnagno | all right, we'll look into these | 11:03.59 |
| | thank you very much | 11:04.06 |
| kens | You're very welcome | 11:04.17 |
| henrys | kens:I think many of the "rop" issues I've seen so far would be resolved by pdf recognizing the rop device is being used in the image code. We looked at that together a while back. | 13:49.11 |
| kens | Yes I remember it well | 13:49.27 |
| | The problem is how to render at that point, but it might be possible, we do it for transparenyc | 13:50.02 |
| | One day I must look into it | 13:54.02 |
| henrys | not a lot of pressure for a solution at this point | 13:54.24 |
| kens | IIRC the problem is that we need the entire page canvas, with all the non-rop stuff already rendered | 13:54.33 |
| henrys | I think blank detection would avoid that in many cases. | 13:56.57 |
| kens | Yes, probably | 13:57.06 |
| | But there would presumably still be some where the canvas is not blank and we need to render the ROP | 13:57.34 |
| henrys | yes indeed | 13:58.17 |
| kens | So the problem is how do we know what to render, since the default is 'ROP' | 13:59.07 |
| henrys | you can't, we could render everything and just use it as scratch - ie not render completely to tiff or something and wrap it. | 14:01.17 |
| | by catching the rop device I was hoping to catch a few more cases but it will never be 100% without rendering everything. | 14:01.59 |
| | brb | 14:06.10 |
| Robin_Watts | ahaha. | 14:16.12 |
| henrys | sounds encouraging | 14:16.57 |
| Robin_Watts | Found a silly typo that explains some diffs (and probably some indeterminisms) | 14:18.22 |
| | mvrhel_laptop: Morning. | 14:28.59 |
| | I think I figured out the vertical lines in images thing. | 14:29.10 |
| henrys | kens:interestingly the scratch frame buffer could also be used for your recent problem with the page size transparency group. | 14:29.52 |
| kens | henrys which problem ? THe full page thing ? | 14:30.07 |
| henrys | the mail to tommy | 14:30.20 |
| | today | 14:30.31 |
| kens | Err, I haven't sent him one today, teh one from Marcos ? | 14:30.51 |
| | That is the full page trsansparency buffer | 14:31.00 |
| henrys | oh yes from marcosw quoting you. | 14:31.17 |
| kens | :) | 14:31.21 |
| | Yeah that's a PDF file that declares a transparency group covering the whole page | 14:31.36 |
| | Its a bit different from ROPS I think | 14:31.43 |
| Robin_Watts | The timings given by marcosw's regression stuff: | 14:55.09 |
| | cpu time current previous difference | 14:55.19 |
| | total 31:44:58 31:28:07 00:16:51 | 14:55.21 |
| | What are the units there? | 14:55.25 |
| | 31 minutes seems too low (elapsed time for cluster job was 29 minutes, split over 14 nodes, of which (say) 7 minutes on each was compile time) | 14:56.32 |
| henrys | I don't see what else it could be. | 14:56.45 |
| Robin_Watts | hours. | 14:57.18 |
| | 5 jobs at a time running in parallel on 14 nodes would need to take 17.5 minutes per node to add up to 31:45 hours. | 14:58.34 |
| henrys | ah right | 14:59.05 |
| Robin_Watts | no, I screwed the maths up. | 14:59.17 |
| henrys | but it is hours | 14:59.55 |
| Robin_Watts | 27 minutes a node. | 14:59.59 |
| | yeah, I think it must be. | 15:00.05 |
| | OK. Vertical line fix pushed. The bmpcmp is compelling :) | 15:04.29 |
| kens | Accdording to Marcos it is hours | 15:04.44 |
| Robin_Watts | My color usage patch produces a 25 minute slowdown. | 15:05.18 |
| kens | Oh that's not ideal | 15:05.26 |
| Robin_Watts | which seems significant. | 15:05.30 |
| kens | coffee time | 15:06.13 |
| Robin_Watts | The color usage thing seems a bit bonkers overall. | 15:10.48 |
| kens | So no difference to anything else then | 15:11.09 |
| Robin_Watts | We go to great lengths to collect the data (which isn't even accurate) and then never *really* use it anywhere. | 15:11.12 |
| kens | So why not do away with it then ? | 15:11.29 |
| Robin_Watts | because we do kinda use it in the ppm devices, I think. | 15:12.02 |
| | and the clist stuff uses it to detect marked or not bands. | 15:13.31 |
| kens | So it is used then. | 15:14.05 |
| henrys | hmm the color_used.slow_rop should be obsolete. | 15:16.09 |
| | since we no longer support the wts device | 15:16.40 |
| Robin_Watts | kens: Right, it's "used", but in a wierd way. I mean, why collect information on what colors are used if you're only going to need marked or not ? | 15:17.40 |
| | And for some spaces the 'marked or not' test is completely wrong. | 15:17.56 |
| kens | Robin_Watts : no idea, I have no idea what the devices do with the info :-) | 15:18.00 |
| Robin_Watts | And there is the "band complexity" stuff that's based on it, but is basically unused currently (from what I gather talking to ray) | 15:18.46 |
| kens | shakes head in wonderment | 15:19.05 |
| Robin_Watts | I guess we (I) should try and understand what's actually used, and strip it back so we just gather enough for that. | 15:20.15 |
| | If it's simply "marked or not", we can do that a lot quicker... | 15:20.29 |
| henrys | chrisl:that is difficult for me to believe about memcpy on msvc it expands to the basic rep move instructions, on linux I see sse3 and on the mac it looks like 64 bit moves, which arch are did Robin_Watts find slower? | 15:52.25 |
| Robin_Watts | henrys: See my comment on the bug. | 15:52.56 |
| kens | Which bug ? | 15:53.08 |
| chrisl | henrys: I can't remember - maybe my memory was playing tricks. I *thought* Robin had made some performance related changes for that reason, but I couldn't find where..... | 15:53.49 |
| Robin_Watts | I don't remember having played with memcpy recently. | 15:54.08 |
| chrisl | Well, my memory is good for this type of thing - but far from infallible! | 15:54.58 |
| Robin_Watts | chrisl: You may be right. My memory is awful. As far as I can remember at least. | 15:55.22 |
| chrisl | Annoyingly, "just" using memcpy involves rather more, and more spread out changes :-( | 15:55.59 |
| henrys | chrisl:I really think we are into premature optimization even if it is faster, if it ever shows up on a profile, fine... | 15:56.04 |
| | chrisl:how's that? | 15:56.23 |
| chrisl | henrys: because the pointers to those arrays are past into other functions which may or may not do the explicit word-wise copying | 15:57.14 |
| Robin_Watts | aha. All the remaining diffs with pushing the maximum number of client colors up to 32 are in PS files. | 15:58.00 |
| | (except 2 which are in pdf files that I think are indeterminate) | 15:58.27 |
| mvrhel | good morning | 15:59.37 |
| | Robin_Watts: good deal about the stripes | 15:59.45 |
| Robin_Watts | mvrhel: Morning | 15:59.48 |
| | How was the ballgame? | 15:59.58 |
| henrys | meeting time, your call chrisl, whatever you think. | 16:00.11 |
| mvrhel | well it was as expected when a team of 5th graders plays a team of 7th graders | 16:00.28 |
| | where one team shaves and another doesnt... | 16:00.58 |
| chrisl | henrys: I'll have another look tomorrow...... I *would* prefer to use memcpy, too | 16:00.58 |
| henrys | why didn't they mix the teams | 16:01.15 |
| | ? | 16:01.16 |
| mvrhel | this is summer ball which is supposed to be a bit more easy going | 16:01.28 |
| | but somehow the teams got very skewed | 16:01.38 |
| | due to a series of buddy requests | 16:01.46 |
| | in spring ball they do a draft with no buddy requests | 16:02.02 |
| | which makes the teams more even | 16:02.08 |
| henrys | mvrhel:you wanted to talk about a bug? | 16:02.23 |
| mvrhel | yes so how do we want to handle my comment about 693185 | 16:02.50 |
| | I do feel like we should have seen a proper warning when things fell apart | 16:03.27 |
| Robin_Watts | mvrhel: Is just upping that array enough? | 16:03.38 |
| mvrhel | yes that solves the issue | 16:03.45 |
| | if we set it to 32 | 16:03.49 |
| Robin_Watts | (i.e. does the code that accesses the array use sizeof or something?) | 16:03.54 |
| mvrhel | which is the max that AR allows | 16:03.55 |
| | for devn | 16:03.59 |
| henrys | why aren't we just set to the AR max? | 16:03.59 |
| mvrhel | That was my comment | 16:04.16 |
| Robin_Watts | Unless there is a good reason, why aren't we setting it to 256 or something? | 16:04.25 |
| | Why only 32 ? | 16:04.30 |
| | We have at least one file that has 40 components in it. | 16:04.43 |
| henrys | we've been screwing around with this forever and the max is documented ... christ | 16:04.44 |
| mvrhel | It is not the num of components in the file in this case | 16:04.55 |
| | but the number within a DevN color space | 16:05.05 |
| Robin_Watts | oh, right. | 16:05.21 |
| mvrhel | I think it is crazy that we have a DevN color space with 17 colorants | 16:05.24 |
| Robin_Watts | Well, 32 seems fine. | 16:05.29 |
| mvrhel | Yes. I think this seems reasonable | 16:05.44 |
| alexcher | Some time ago large values caused severe performance penalty. | 16:05.46 |
| henrys | so up it to 32 and check the our new regression times. | 16:05.54 |
| mvrhel | it would be nice if things degraded with a warning about this when it is exceeded | 16:06.10 |
| | instead the interpreter starts spitting out stuff about qQ | 16:06.21 |
| chrisl | mvrhel: these large devicen spaces seem to have become increasingly common since Adobe's n-channel horror was introduced | 16:06.33 |
| alexcher | Regression is abot 3% slower. | 16:06.38 |
| Robin_Watts | Can we use max(32,GS_CLIENT_COLOR_MAX_COMPONENTS) or is that silly ? | 16:07.03 |
| mvrhel | that is an idea | 16:07.23 |
| Robin_Watts | (or some #ifdeffery to give the same result) | 16:07.38 |
| mvrhel | however, AR will allow more than 32 spots on the page but not more than 32 in a DevN color space | 16:07.50 |
| | so setting it to 32 seems reaonsable | 16:08.05 |
| | this should be less than the 3% that alex is seeing | 16:08.16 |
| | since it is just this structure and not GS_CLIENT_COLOR_MAX_COMPONENTS | 16:08.32 |
| | which he had bumped up | 16:08.36 |
| | I will give it a push and see | 16:08.54 |
| | what is goofy is the image uses a DevN color space with 17 colorants but uses only 2 of them | 16:09.23 |
| henrys | 3% average doesn't tell us a lot, if it significantly slows down something that uses the functionality and doesn't effect other stuff we don't care. | 16:09.27 |
| mvrhel | henrys: true | 16:09.39 |
| | I can't see how the change we are talking about here, would cause a performance issue | 16:10.05 |
| | going from float[14] to float[32] | 16:10.16 |
| henrys | marcosw1:could you quantify this performance change for us on individual fines? | 16:10.41 |
| | s/fines/files | 16:10.49 |
| Robin_Watts | henrys: clusterpush once with filter=psdcmyk and no change. | 16:11.26 |
| | Then clusterpush again with filter=psdcmyk and the change. | 16:11.38 |
| | and manually compare times? | 16:11.42 |
| henrys | it would be funny if the slowdown was due to files not having limitchecks ;-) | 16:11.53 |
| Robin_Watts | Oh, sorry, this was for non spot devices. | 16:12.03 |
| mvrhel | right | 16:12.10 |
| Robin_Watts | You can filter=name to restrict to particular names of files if there is a desired subset you want to test? | 16:12.38 |
| mvrhel | perhaps the fts pdf files with ppmraw | 16:13.20 |
| henrys | mvrhel:so just assign it back to marcosw1 with a performance test request, he'll probably need an exact description of how to test. | 16:14.05 |
| Robin_Watts | filter=fts,pdf,ppmraw | 16:14.06 |
| | henrys: We can do the testing ourselves (we have the technology :) ) | 16:14.37 |
| henrys | okay fine by me just trying to distribute the load. | 16:14.59 |
| | kens:anything for the meeting, how are you project wise? | 16:15.17 |
| kens | henrys working on linearisation, and customer bug reports | 16:15.35 |
| | The one from 'sri' I'm about to reply to. | 16:15.48 |
| | Its interesting, but I don't know if we want to do anything about it | 16:16.00 |
| henrys | chrisl:how's freetype? | 16:17.15 |
| marcosw | sorry to be late | 16:17.37 |
| mvrhel | marcosw: just sent 693185 back to you | 16:17.55 |
| | we were hoping you could do a performance check for the proposed change | 16:18.21 |
| chrisl | henrys: it's UFST I've been banging on - and it's (almost) all working (does all reasonable fonts for PS/PDF and PCL/PXL). I'm about to go back to test freetype to make sure my changes to handle UFST haven't broken that. | 16:18.32 |
| marcosw | mvrhel: can and will | 16:18.48 |
| mvrhel | marcosw: I doubt it will effect performance and it fixes the issue. thanks | 16:18.54 |
| henrys | chrisl:great news. | 16:19.15 |
| chrisl | henrys: it's looking good, yes :-) | 16:19.29 |
| mvrhel | so, question now | 16:20.11 |
| | about 693207 | 16:20.24 |
| henrys | if it does slow something down it is probably some deficiency in the code we should look at more carefully, I thing the last slowdown alex was talking about was with the stupid clues, which you've most fixed. | 16:20.26 |
| mvrhel | which has the same file | 16:20.29 |
| | this will solve that issue also | 16:20.36 |
| | unless they are trying to get separations | 16:20.47 |
| | and want all the separation | 16:20.54 |
| | s | 16:20.55 |
| | do you know what device the customer is rendering to marcosw? | 16:21.21 |
| kens | henrys I've sent a reply to customer #680 about the PDF file sizes. I'd be interested to know what you think based on my (very preliminary) findings. | 16:21.57 |
| henrys | kens:I'll have a look. | 16:22.12 |
| | ray_work? | 16:22.33 |
| kens | I'd be interested in other opinions too based on what's in the email | 16:22.33 |
| marcosw | customer 393 always renders to tiffsep (at 400 dpi) | 16:23.02 |
| mvrhel | ok | 16:23.15 |
| | so they probably want the separations then. | 16:23.31 |
| | we should just tell them to build it with the larger value (32) if Robin_Watts has that fixed | 16:24.13 |
| kens | We have to build it for them :( | 16:24.30 |
| Robin_Watts | mvrhel: Still looking at that now. | 16:24.35 |
| mvrhel | I thought we quit that | 16:24.35 |
| kens | mvrhel : no... :( | 16:24.44 |
| henrys | tor8:I don't think we need to shift around forms meeting you can just miss one. Paul and Robin_Watts are fairly available on IRC whenever you want to talk. | 16:24.46 |
| chrisl | mvrhel: if 393 is who I think it is, no, they don't use the seps, the only use tiffsep to get the (ahem) accurate overprint in the preview. | 16:24.54 |
| mvrhel | oh | 16:25.05 |
| Robin_Watts | henrys: The most immediate thing for the forms work is for us to get a reviewed merge of forms -> trunk done for the release, I think. | 16:25.43 |
| kens | customer #393 is Gemma if that helps chrisl | 16:25.46 |
| henrys | does anyone have anything for ray, if so I'll text him? | 16:25.51 |
| kens | Not me | 16:25.58 |
| | Spoke to him this morning | 16:26.05 |
| Robin_Watts | I wanted to talk to ray (and others) about the color usage stuff | 16:26.08 |
| chrisl | kens: Yes, thanks, that's who I thought it was..... | 16:26.13 |
| henrys | okay I've texted him. | 16:27.41 |
| | any other non ray issues? | 16:27.52 |
| mvrhel | when is the freeze date? | 16:28.07 |
| marcosw | chrisl: I didn't realize that customer 393 only uses the composite tiffsep output. Seems like there should be a ghostscript device to product just that | 16:28.10 |
| henrys | should we talk about the release? | 16:28.15 |
| kens | I'm keeping my head down until after the release, not doing dangerous stuff, working on more long-term issuews | 16:28.23 |
| henrys | I have a very large change that is getting bigger than I'd like so the sooner the release can go the better for me. | 16:29.00 |
| kens | thinks earlier is better | 16:29.17 |
| | Its August in a week | 16:29.23 |
| | Hi ray_laptop | 16:29.47 |
| Robin_Watts | I'm away for a weeks holiday in August, so I'd really like the release done then :) | 16:29.47 |
| henrys | kens:yeah can you believe that? time flies. | 16:29.53 |
| chrisl | henrys, mvrhel: I'm taking a couple of days off (2 & 3rd Aug), I'd like to get the release candidate out before then, if I can. | 16:29.54 |
| mvrhel | probably as soon as ray gets his fix in for hl_color_rect fill and Robin_Watts wraps up his fixes I think we should go ahead | 16:30.03 |
| | not sure if alexcher is going to get the softmask fix in | 16:30.15 |
| kens | Suits me | 16:30.18 |
| ray_laptop | sorrry I forgot to start chatzilla | 16:30.23 |
| kens | RC as soon as blockers are cleared | 16:30.29 |
| alexcher | mvrhel: I'll try. | 16:30.32 |
| Robin_Watts | mvrhel: I'd really like that fix from alex in, if it's going to come soon. | 16:30.35 |
| henrys | I do a half ironman on the 5th and might not leave bed for some time after so early is best for me. | 16:31.42 |
| ray_laptop | chrisl: what was the critical date for ubuntu ? | 16:32.06 |
| mvrhel | it was late in august | 16:32.15 |
| kens | IIRC 2nd week in August for us to release | 16:32.23 |
| ray_laptop | mvrhel: thanks | 16:32.25 |
| chrisl | ray_laptop: something like 24th, IIRC | 16:32.32 |
| Robin_Watts | release was late, freeze was before that. | 16:32.40 |
| | IIRC. | 16:32.45 |
| ray_laptop | so with people taking time off, the earlier the better. | 16:33.29 |
| Robin_Watts | so... any other business before the color_usage stuff ? | 16:33.37 |
| henrys | I'm done | 16:33.47 |
| chrisl | Just to clarify, Ubuntu 12.10 feature freeze is August 23rd | 16:34.10 |
| mvrhel | Robin_Watts: do I need to be here for the color_usage stuff? Need to run car to the tire shop. they do have wi-fi there | 16:34.11 |
| kens | I'd like to run if we are done. | 16:34.20 |
| Robin_Watts | mvrhel: Probably not. | 16:34.22 |
| | mvrhel: but if you have any opinions obviously... | 16:34.34 |
| mvrhel | ok. I will be back on in 20 assuming the wif-fi is working there. | 16:34.42 |
| Robin_Watts | have fun. | 16:34.51 |
| mvrhel | $ | 16:34.57 |
| chrisl | henrys: if your changeset is getting that big, maybe you need a branch in your repo on casper :-) | 16:35.17 |
| kens | I can review the logs later, I don't expect to contribute to the color_usage stuff as I know nothing about it | 16:35.24 |
| Robin_Watts | kens: That never stops me :) | 16:35.34 |
| kens | Yeah but I'm supposed to be going out to eat | 16:35.50 |
| henrys | chrisl:I will push it, but it isn't of much use since pcl is sort of a solo project. | 16:36.05 |
| Robin_Watts | So, quick precis of the color_usage stuff: | 16:36.18 |
| | Patch is at: http://git.ghostscript.com/?p=user/robin/ghostpdl.git/.git;a=commitdiff;h=47cf40c87f20f12d8f35528adedb102d2d0dcef2 | 16:36.22 |
| ray_laptop | Robin_Watts: it looks OK as far as the patch goes. | 16:36.50 |
| chrisl | henrys: if it getting non-trivial, it's good to have it somewhere off-site, anyway - you never know..... | 16:37.09 |
| Robin_Watts | ray_laptop: The tests of that patch show no (non indeterminate) diffs. | 16:37.24 |
| | The problem is, it's 25 minutes slower (out of 31.75 hours) | 16:37.43 |
| kens | OK I need to run, will review the logs later. Have fun discussing :P | 16:38.02 |
| henrys | chrisl:right you are. | 16:38.04 |
| kens | Robin_Watts : 25 minutes is not that great I thought you said 25% | 16:38.13 |
| ray_laptop | Robin_Watts: right, that's within the noise of normal times | 16:38.22 |
| Robin_Watts | no, 25 minutes :) | 16:38.25 |
| | I think 25 minutes is high for noise. | 16:38.37 |
| kens | High, but not excessive | 16:38.45 |
| | Probably indicats *sopme* slowdown, but may not be much | 16:38.56 |
| | Anyway got to run | 16:39.04 |
| | See you all later | 16:39.07 |
| Robin_Watts | kens: night. | 16:39.08 |
| | Henrys points out that the slow_rop stuff is never used. | 16:39.25 |
| ray_laptop | Robin_Watts: is the 'gs' time still skewed by you partial run? gs 19:18:14 04:56:34 14:21:39 | 16:39.57 |
| Robin_Watts | ray_laptop: Where are you getting that from? | 16:40.49 |
| henrys | marcosw:is there a log from which these time stats are gathered or are the intermediate results thrown away? | 16:41.07 |
| Robin_Watts | ray_laptop: I mailed you the relevant report, which was for a full test. | 16:41.42 |
| marcosw | they timing data is in the githash.tab file located on casper in ~cluster/cluster/archive | 16:41.53 |
| Robin_Watts | gs 19:18:14 19:01:52 00:16:21 | 16:41.54 |
| ray_laptop | from the regression following the email you sent. but I see a subsequent email that gs takes 19:01:52 so the color_usage didin't affect that | 16:42.13 |
| marcosw | e.g. tests__Ghent_V3.0__010_CMYK_OP_x3.pdf.ps.pkmraw.300.0 0 1.26 1.46 0 0 a8528ff1e48f83a8f76026b7d201dd31 0 gs ps2write peeves | 16:42.24 |
| Robin_Watts | ray_laptop: I'm confused. | 16:42.53 |
| marcosw | columns 3 and 4 are the timing data | 16:43.01 |
| | in this case column 3 is the pdf to ps time and column 4 is the ps to pkmraw time | 16:43.20 |
| ray_laptop | Robin_Watts: nm. the gs times look OK with color_usage | 16:43.22 |
| Robin_Watts | I'm testing other patches, for both full and subset runs, so the only meaningful timing data you have to comment on should be the regression email I forwarded you. | 16:43.44 |
| marcosw | for tests that don't have an intermediate ps or pdf file column 4 is 0. | 16:43.45 |
| Robin_Watts | OK. | 16:43.47 |
| | So I'll commit the color_usage patch as it. | 16:43.55 |
| marcosw | you also need to pay attention to column 2, which is the error (i.e. if a file errors out you probably want to disregard the timing data :-) ) | 16:44.17 |
| Robin_Watts | As far as I can see it's only the clist that looks at it. | 16:44.34 |
| | marcosw: So if we time out, we get an error, and we throw away that line... and we get faster times? | 16:44.56 |
| marcosw | yup :-) | 16:45.25 |
| | but presumably you'll notice the large number of timeouts in the regression email and realize something is up. | 16:45.49 |
| ray_laptop | so more timeouts is also a separate red-flag | 16:45.50 |
| Robin_Watts | ray_laptop: Sorry, that was unclear. as far as I can tell, there are few users of the color_usage data we collect; possibly only the clist which calculates whether a band is marked or not by looking at it. | 16:46.03 |
| marcosw | I guess I should modify the timing data to add in the maximum time-out value for files which timeout, it's better than adding zero. | 16:46.50 |
| Robin_Watts | Would we be better just calculating a 'marked' or not bool for each band rather than the color usage ? | 16:47.00 |
| | marcosw: That would be the best we can do, I think. | 16:47.15 |
| ray_laptop | Robin_Watts: the color_usage was intended to allow skipping planes, and also to allow a device to look at the color_usage for the entire page to see if it can be printed in black only | 16:48.12 |
| marcosw | there is still and issue for files that generate a different error, but again, those will be in the report and should raise red flags. | 16:48.19 |
| ray_laptop | the latter is very handy for color printers that can save toner or run faster in black only mode | 16:48.57 |
| Robin_Watts | ray_laptop: Right, and I thought that the p?m devices used that, but I can't see it now. | 16:49.57 |
| | but even so, the code we have does NOT work for that case. | 16:50.07 |
| | If I draw something red, then something green, then something blue, it all gets orred together to give a colors_used field of ffffff, and we spot that as being black (or white). | 16:50.51 |
| ray_laptop | Robin_Watts: gdevpbm.c calls gdev_prn_colors_used | 16:50.57 |
| Robin_Watts | ray_laptop: Right. that was my memory, but I couldn't find it when I grepped earlier. | 16:51.24 |
| ray_laptop | and you are right, that's only good in subtractive colorspace | 16:51.41 |
| marcosw | Robin_Watts: it's a bit problematic for two reasons, timeouts occur in walk clock time (5 minutes, I think), but the reports track cpu time. The other is what to do when the timeout occurs during the input ->pdfwrite step. I can add 5 minutes to that time but adding 5 minutes to the pdf->bitmap steps isn't reasonable... | 16:52.47 |
| ray_laptop | Robin_Watts: I was going to put the fix for polarity in after your patch (unless you want to include that inyour patch) | 16:53.14 |
| Robin_Watts | marcosw: Fair enough. | 16:53.16 |
| | ray_laptop: No. I'll just commit my patch as is for now. It's certainly no worse than the old code. | 16:53.34 |
| ray_laptop | Robin_Watts: in your git diff, gdevpbm.c is the first changed file | 16:53.52 |
| marcosw | Robin_Watts: I'll do the quick and dirty thing for now and think about it on my drive to uni (which I need to leave for in 10 minutes). | 16:53.55 |
| Robin_Watts | ray_laptop: Yeah, ok, I'm blind :) | 16:54.30 |
| ray_laptop | Robin_Watts: it looks like it is only used in 'psm_print_page' (separations), so that should be subtractive | 16:55.58 |
| | the (never used) pksm and pksmraw devices | 16:56.46 |
| marcosw | Robin_Watts: actually, the correct thing to do is to remove the times for files that timed out in the current or previous run and then report the number of files that timed out in separately⦠Or we could just remove those files that often timeout from the regression tests, since they don't produce useful results in any case. | 16:58.36 |
| Robin_Watts | marcosw: My worry was that someone could make a change that tipped a few more files over into timeouts, and we'd see the total time for the run decrease. | 16:59.16 |
| ray_laptop | marcosw: IMHO, we need to try those files sometimes (in the modes that timeout) to see if any stop timing out and put them back in the test | 16:59.37 |
| | marcosw1: if it automatically moves files that timeout to a do not run list, one bad patch could move everything out ti the timeout quarantine | 17:00.57 |
| | if we manually remove files that timeout, then we'd know when the timing 'glitched' | 17:01.46 |
| | it just makes it hard to go back and compare 'history' to see trends, but since we continually change the tests anyway (adding new files), I'm not sure how useful history is | 17:03.19 |
| henrys | bbiab moving to the coffee shop | 17:03.25 |
| ray_laptop | OK. I'll get my coffee now too and brb | 17:03.44 |
| henrys | oh that was stupid I'd always thought there was relative moves. | 17:07.20 |
| Robin_Watts | Why do errors with PS files always have to be on page 12 rather than page 1 ? | 17:11.45 |
| | henrys: The omission of relative moves, and of horizontal and vertical line segments are indeed strange. | 17:17.03 |
| | Interesting. A debug build of gs (even without my changes) gives a clist warning message on 12-07C.PS | 17:22.43 |
| mvrhel_laptop | Robin_Watts: I noticed that before and have an open bug on this | 17:58.59 |
| | about 12-07C.ps | 17:59.04 |
| Robin_Watts | mvrhel_laptop: Right. I wonder how many of these changes I'm seeing are down to such things. | 17:59.21 |
| | I've got a simplified file I'm just looking at now. | 17:59.36 |
| mvrhel_laptop | oh good | 17:59.42 |
| Robin_Watts | It's a set color going wrong into the clist I think. | 18:20.41 |
| | mvrhel_laptop: Is gx_devn_write_color yours ? | 18:28.58 |
| mvrhel_laptop | I wrote this yes | 18:29.22 |
| Robin_Watts | count = gx_dc_devn_get_nonzero_comps(pdevc, dev, &mask); | 18:30.04 |
| | That gets a mask, with 1 bit per component, showing the usage I reckon. | 18:30.18 |
| mvrhel_laptop | write | 18:30.24 |
| | right | 18:30.26 |
| Robin_Watts | Oh, ignore me | 18:30.39 |
| | SOrry. | 18:30.41 |
| mvrhel_laptop | ugh 4 new tires on this car. a small fortune | 18:31.56 |
| Robin_Watts | will bet it's cheaper than mine :) | 18:32.14 |
| | What car? | 18:34.40 |
| | (Actually, if it's an SUV, you may pay more purely for the size of the tyres) | 18:35.16 |
| mvrhel_laptop | it is a mercedes | 18:36.49 |
| | with low profile tires | 18:36.57 |
| Robin_Watts | My mazda RX8 takes similarly low profile things. | 18:37.24 |
| mvrhel_laptop | ok. you would think with less material it would be cheaper.... | 18:37.47 |
| Robin_Watts | Fortunately, my neighbour runs a garage, and I fix his computers - so I get tyres at cost. but even so it's a sizeable whack each time. | 18:37.59 |
| mvrhel_laptop | nice | 18:39.08 |
| Robin_Watts | mvrhel_laptop: As far as I can tell, whenever you write/read a devn color you leave a spare unused byte at the end. | 18:49.04 |
| | I can't see how that can be causing a problem, but... | 18:49.18 |
| mvrhel_laptop | hmm that is odd | 18:49.47 |
| | Robin_Watts: why don't you attach the simplified file to my bug and I will look it over | 18:50.16 |
| Robin_Watts | I'll bash on for a while longer. | 18:50.39 |
| ray_laptop | I just put 4 new tires on our mini-van as well. about $500 | 18:57.06 |
| | but at least I got lots of miles out of the last ones | 18:57.40 |
| mvrhel_laptop | ray_laptop: try almost 2x that :( | 18:59.13 |
| ray_laptop | mvrhel: really ? both my SUV and my minivan were about the same price. The minivan uses 15" the SUV uses 17" -- yours are probably larger wheel size -- the price really starts going up with larger wheels | 19:04.54 |
| | a friend that has a porsche pays about $600 per tire (and gets about 30K miles on a set) | 19:06.21 |
| Robin_Watts | low profile tyres cost a lot. I bet mvrhel's are run flat too. | 19:07.23 |
| mvrhel | yes. they are wide and low profile | 19:40.30 |
| Robin_Watts | mvrhel_laptop: ping | 20:15.35 |
| cryptopsy | why doesn't gaxb produce a larger page output that the input file? | 20:15.49 |
| | -g5000x5000 for example | 20:15.49 |
| Robin_Watts | I think I've got it narrowed down a bit. It's going wrong (I think) in a clist_copy_mono call (from mask_clip_fill_rectangle). | 20:17.03 |
| cryptopsy | -g takes precedence over the default size and seets -dFIXEDMEDIA | 20:17.19 |
| Robin_Watts | It's deciding it needs to do cmd_set_color1 | 20:17.37 |
| | And that goes wrong, because num_bytes is being calculated as 14, and we only have cmd_delta_offsets defined for up to 7. | 20:19.54 |
| cryptopsy | even -dDEVICEWIDTHPOINTS=w -dDEVICEHEIGHTPOINTS=h don't increase output file width | 20:22.03 |
| | -dFIXEDMEDIA doesn't help | 20:25.50 |
| | which tiff driver in section 7.2 produce lossless compression? | 20:29.41 |
| ray_laptop | Robin_Watts: so the "real" regression timing has the color_usage change actually faster. Now I'll see if I can slow it down by adding in POLARITY ;-) | 20:44.19 |
| Robin_Watts | mvrhel_laptop: ping? | 22:27.43 |
| | mvrhel_laptop: (For the logs if you're not about). It looks to me like cmd_put_color doesn't know how to deal with devn colors; it can only put color_indexes. | 22:29.07 |
| | So, that needs to be extended. I'll have a look tomorrow. | 22:29.38 |
| | Forward 1 day (to 2012/07/25)>>> | |
IRC Logs