| | <<<Back 1 day (to 2011/12/12) | 2011/12/13 |
| Robin_Watts | kens: Your faq entry... Reading it immediately makes a load more questions spring to mind. | 10:19.21 |
| kens | OK which ones ? | 10:19.30 |
| Robin_Watts | Could I suggest a "What are PDF-A, PDF-A1, PDF-A2?" question | 10:20.01 |
| kens | Well we could do that, but there are plenty of non-Ghostscript sources for that (eg Wikipedia has a good entry) | 10:20.26 |
| Robin_Watts | Where you state what the intention of the different things is, and how they differ. | 10:20.31 |
| | A link or two in the FAQ "for more information see..." wouldn't be a bad thing, but it'd be nice to have in the same place as the above FAQ entry. | 10:21.31 |
| kens | To my mind hits is a *Ghostscript* FAQ, if you want answers to generic questions you should look elsewhere. | 10:21.54 |
| | Otherwise the thing will spiral out of control. | 10:22.13 |
| Robin_Watts | Especially as it can lay the groundwork for explicitly saying "The spec says that producers SHOULD NEVER GUESS when producing PDF-A" | 10:22.16 |
| kens | That's in there. | 10:22.28 |
| | I'm unconvinced, we've never had anyone ask 'what is PDF/A ?' | 10:23.05 |
| chrisl | Henry specifically said we *don't* want to descend into being a general Postscript/PDF/PCL/PXL/XPS FAQ | 10:23.50 |
| Robin_Watts | My impression, albeit it as a relatively uninformed outsider, is that lots of people that have come to us asking questions about why we don't support particular PDF-A variants have no clue at all what they are actually asking for - they are just seeking to have a box ticked. | 10:24.45 |
| kens | Right, so thre's the answer why they can't have a box ticked. | 10:25.09 |
| | If they wanted to be educated they would look elsewhere first. | 10:25.22 |
| | The customer was happy with the answer.... | 10:25.35 |
| | Hmm, chrisl your new code (congrats on that) seems ot have produced a new seg fualt with pdfwrite output. | 13:16.28 |
| chrisl | kens: sorry, phone. Oops, I didn't notice that. I wonder if pdfwrite doesn't handle the cmap table setup in droidsansfallback..... | 13:31.57 |
| kens | Could be, I only noticed there were two new seg faults. | 13:33.45 |
| | I'll pull the code and build it to see what happens. | 13:34.04 |
| chrisl | Hmm, no it's crashing in pdf_text_set_cache() | 13:34.45 |
| kens | :-( | 13:34.54 |
| chrisl | Because penum->pte_default == NULL | 13:35.18 |
| kens | I thought it was the produced PDF file that was causing the seg fault | 13:35.20 |
| | That should not be possible. | 13:35.31 |
| chrisl | Not for me, no | 13:35.32 |
| kens | code updated, rebuilding now | 13:35.48 |
| | regression test log says it crashes with the transformed file: | 13:36.36 |
| | tests_private/comparefiles/Bug692320.pdf.pdf.pkmraw.300.0 kilometers Seg_Fault | 13:36.36 |
| chrisl | I'm guessing that line just signifies the test path it was performing, but doesn't ID which stage in the path actually crashed | 13:37.43 |
| kens | It should only get there if its falling back to the default implementation, and rendering the glyph as a type 3. | 13:38.04 |
| | In which case pte_default shouldn't be NULL. | 13:38.28 |
| | Just getting file from SVN | 13:40.08 |
| | Odd, no debugging information.... | 13:41.37 |
| | Must be linking against the release DLL | 13:41.59 |
| | But you are right, its crashing for me while doing the conversion. | 13:44.44 |
| | I guess I don't understand the cluster well enough, I wonder if its possible for Marcos to determine if the error was during conversion to PDF or rendering the converted PDF. | 13:45.36 |
| chrisl | I don't think it's that important, you have to go through both steps to reproduce anyway | 13:46.23 |
| kens | Huh ? If it fails at teh conversion stage, then that's fatal. | 13:46.46 |
| | OK rebuild done, lets see if I get debugging symbols this time | 13:47.41 |
| chrisl | I'd say crashing at either is pretty fatal - we can't really ship if we can't consume our own PDF! | 13:48.02 |
| kens | Yeah, but there's a big difference between crashing during conversion, and crashing reading our PDF. | 13:48.24 |
| | OK so we are accumulating a type 3 CharProc it looks like | 13:48.46 |
| chrisl | I really don't think we should be, given it started life as a TTF | 13:49.18 |
| kens | Well, that just may mean the boolean is wrong. | 13:49.38 |
| | On the plus side, it fails instantly | 13:50.14 |
| | We are processing it as a composite font of some kind | 13:51.01 |
| | CIDFont it appears | 13:51.25 |
| chrisl | Well, it's a TTF substituted for a CID font, so that makes sense | 13:51.29 |
| kens | CID = 0x495, font index is 0, subfont FontType is 11 | 13:52.57 |
| | No Unicode value available it seems | 13:54.19 |
| | Well, exiting to run the CDevProc | 13:54.52 |
| | That's bad.... | 13:55.50 |
| | Running the CDevProc ends us up in the cache device. | 13:56.04 |
| chrisl | I'm confused - is it trying to build a type 3, here? | 13:56.46 |
| kens | No. | 13:56.52 |
| | Its executing a CIDFont, and gets as far as running the CDevProc (if any). | 13:57.09 |
| | And somehwo ends up in the cache code while running CDevProc. | 13:57.25 |
| chrisl | Okay, less confused. I wonder if this is unique to DroidSansFallback | 13:58.29 |
| kens | We end up there from zchar42_set_cache() | 13:58.31 |
| | I don't think we should be in there at this time. | 13:58.58 |
| | As I recall the PDF interpreter does some kooky stuff with the CDevProc, so we *always* have one. | 13:59.25 |
| | It sort of looks like zshow isn't detecting the fact that we are exiting to run the CDevProc. We are *supposed* to go back to pdf_text_process after the CDevProc is executed, and carry on. | 14:00.29 |
| | OK, in op_show_continue_dispatch we do go into the 'CDevProc' case, so carrying on from there./ | 14:01.29 |
| | Hmm, it then does indeed call set_cache. | 14:02.04 |
| | I'm sure this used to work.... | 14:02.22 |
| | But that may be before I did all the PCL rework.... | 14:02.34 |
| | Hmm, chrisl, look at zcharout.c, line 216. | 14:03.45 |
| | Still doesn't explain the crash though | 14:04.03 |
| | I bet I broke this with the PCL code, and nobody noticed because we don't test CIDFont substitution. | 14:05.50 |
| chrisl | Well, it doesn't work with a TTF font added in cidfmap, so it's nothing specific to my changes, nor to DroidSans. Nor even to that test file...... bugger :-( | 14:06.39 |
| kens | Yeah, looks like I broke it a while ago. Going to have to figure out why now. | 14:06.59 |
| chrisl | Your reasoning seems sound | 14:08.24 |
| kens | Well I did recode that entire area. So I'm betting its soemthing stupid I've done. | 14:08.46 |
| | I'll go look at the old code I guess. | 14:09.02 |
| chrisl | It looks to me as though pdfwrite needs to understand that we might not execute the CDevProc. | 14:09.41 |
| kens | I think that's what I broke. | 14:10.02 |
| chrisl | I wonder if we could retrieve the CID so that we could run the CDevProc after all | 14:10.38 |
| kens | I don't think that's neccesary, this did work before (I think) | 14:11.07 |
| chrisl | True, but it would (arguably) be better if we could use the CDevProc | 14:11.53 |
| kens | I'm not sure, I don't know if the CDevProc has any value here. | 14:12.12 |
| chrisl | For the widths info? | 14:12.37 |
| kens | Well, according to the old code, it should still exit with an error under this circumstance. | 14:15.10 |
| chrisl | I'm pretty sure we could get the CID here: at worst, I think we have the original string input, and the font available | 14:18.22 |
| | Have to feed to the cat, back in a minute..... | 14:18.33 |
| kens | Where is here ? | 14:18.34 |
| chrisl | zchar_set_cache() | 14:18.46 |
| kens | OK, need to think about this some more and do some debugging. | 14:19.02 |
| | reverting to 9.0 for a minunte | 14:19.08 |
| | Huh, 9.0 won't run the file.... | 14:21.04 |
| chrisl | Missing CIDFont | 14:21.19 |
| kens | No, 'corrutp EOF' | 14:21.27 |
| chrisl | Oh | 14:21.48 |
| kens | Better be 9.02 I suppose. | 14:22.16 |
| chrisl | Well, any file with a missing CIDFont should show the problem | 14:22.57 |
| kens | Yeah, but I would like to track the old code with this file | 14:23.15 |
| chrisl | "old code" as in pre-PCL font changes? | 14:23.52 |
| kens | Yes, correct. | 14:24.00 |
| | Unfortunately I don;t remember when I made them. | 14:24.11 |
| | 29th April apparently | 14:25.15 |
| Robin_Watts | kens: You can tell when it crashed by looking at the logs. | 14:26.42 |
| kens | I don't think so. | 14:26.54 |
| Robin_Watts | Let me look. | 14:27.18 |
| kens | Don't worry, I have the commit where I changed the code. | 14:27.30 |
| | I can revert to before that. | 14:27.38 |
| Robin_Watts | Which file ? | 14:27.41 |
| kens | huh ? | 14:27.54 |
| chrisl | Robin_Watts: this requires a configuration we don't test on the cluster | 14:28.00 |
| kens | Exactly | 14:28.10 |
| Robin_Watts | Sorry, I've just got back from lunch, was skimming the logs, and replied to: "kens>I guess I don't understand the cluster well enough, I wonder if its possible for Marcos to determine if the error was during conversion to PDF or rendering the converted PDF." | 14:28.49 |
| | And the answer is, yes, you can tell by looking at the logs. | 14:29.02 |
| kens | OK, well that would be interesting, but I'm sure I know the answer | 14:29.19 |
| Robin_Watts | I believe you can tell from the error codes anyway. | 14:29.35 |
| | Seg_Fault = During Conversion. | 14:30.04 |
| kens | Well if you want to look its Bug692320.pdf.pdf | 14:30.20 |
| Robin_Watts | Seg_Fault_reading_Ghostscript_produced_PDF/PS_File = During rendering | 14:30.22 |
| | That didn't fail on your last clusterpush. | 14:30.39 |
| kens | It just says 'Seg_Fault' | 14:30.41 |
| Robin_Watts | Then that's during the first stage. | 14:30.50 |
| kens | Not my cluster push, Chrisl's commit | 14:30.52 |
| | git | 14:32.18 |
| | Oops :-) | 14:32.26 |
| | git reset help | 14:32.50 |
| chrisl | Sorry, I didn't mean to cause all this trouble - but no need for name calling...... | 14:32.53 |
| kens | Someone remind me how to tell Git to go back to a specific versoin please ? | 14:33.56 |
| Robin_Watts | git checkout <hash> | 14:34.04 |
| kens | OK thanks | 14:34.10 |
| | chrisl can you tell me what cidfmap entry to use with this file, and where can I get the DroidSans font ? | 14:34.44 |
| Robin_Watts | The 2 machines that got the SEGVs were x6 and kilometers. on the dashboard click on 'logs' next to the commit, and choose the appropriate logs. Then search for the filename. | 14:35.35 |
| | I'm doing that now, but it's taking ages cos my broadband-fu is weak. | 14:35.50 |
| kens | Its not that vital. | 14:35.55 |
| | I'm sure chrisl and I are lokking at the problem | 14:36.08 |
| Robin_Watts | And yes, it SEGV'd in the first half. | 14:36.35 |
| kens | As expected. | 14:36.45 |
| Robin_Watts | gs pdfwrite | 14:36.46 |
| | ./gs/bin/gs -sOutputFile=./temp/tests_private__comparefiles__Bug692320.pdf.pdf.ppmraw.300.0.pdf -sDEVICE=pdfwrite -r300 -sDEFAULTPAPERSIZE=letter -dNOPAUSE -dBATCH -dClusterJob -dJOBSERVER ./tests_private/comparefiles/Bug692320.pdf | 14:36.47 |
| | GPL Ghostscript 9.05 (2011-03-30) | 14:36.49 |
| | Copyright (C) 2010 Artifex Software, Inc. All rights reserved. | 14:36.51 |
| | This software comes with NO WARRANTY: see the file PUBLIC for details. | 14:36.53 |
| | **** Warning: Invalid Page count. | 14:36.54 |
| | Processing pages 1 through 32. | 14:36.56 |
| | Page 1 | 14:36.58 |
| | Can't find CID font "ÃÃÃùÃÃ
Ã". | 14:36.59 |
| | Attempting to substitute CID font /Adobe-Korea1 for /ÃÃÃùÃÃ
Ã, see doc/Use.htm#CIDFontSubstitution. | 14:37.01 |
| | The substitute CID font "Adobe-Korea1" is not provided either. attempting to use fallback CIDFont.See doc/Use.htm#CIDFontSubstitution. | 14:37.02 |
| | Loading a TT font from %romesource/CIDFSubst/DroidSansFallback.ttf to emulate a CID font CIDFallBack ... Done. | 14:37.03 |
| | **** Warning: Fallback CIDFont in use - glyphs may be incorrect or missing | 14:37.05 |
| | Command terminated by signal 11 | 14:37.06 |
| chrisl | kens: you can get DroidSans from out get repos it's in Resource/CIDFSubst | 14:37.06 |
| Robin_Watts | 0.18 0.01 0:00.55 34% | 14:37.08 |
| chrisl | s/out get/our git | 14:37.24 |
| kens | chrisl given that I've just reverted to a much earlier version, anwhere else I can get it ? | 14:37.32 |
| | Damn, I may give up on using this file, the fonts have CJKV names. | 14:38.37 |
| chrisl | kens: you can reproduce the problem with other TTF fonts and other files. | 14:39.11 |
| kens | Got one you know of ? | 14:39.19 |
| | I have plenty of fonts to substitute, just a file name would be good. | 14:39.39 |
| chrisl | http://bugs.ghostscript.com/show_bug.cgi?id=690798 - thrane.pdf from that bug, and I used batang.ttc | 14:39.58 |
| kens | OK thanks. | 14:40.07 |
| Robin_Watts | kens: You can get files from git.ghostscript.com | 14:40.12 |
| | using the web interface | 14:40.25 |
| kens | Yes Robin_Watts but I need ot know *which* file. | 14:40.29 |
| | Oh you mean the font | 14:40.44 |
| chrisl | kens: then this added to cidfmap (with appropriate path changes): /Arial << /FileType /TrueType /Path (/usr/share/fonts/truetype/msttcorefonts/batang.ttc) /SubfontID 0 /CSI [(Identity) 0] >> ; | 14:40.52 |
| kens | Thanks | 14:41.03 |
| Robin_Watts | yeah, the font. I'm lagging today :) | 14:41.55 |
| kens | OK that seems to eb working at least, now to find out what I breok | 14:43.55 |
| | broke | 14:43.59 |
| | Huh, nothing. | 14:44.21 |
| | It always failed. | 14:44.26 |
| | At least with that file and substitution with pdfwrite | 14:44.39 |
| | Mayeb this always aborted. | 14:44.52 |
| Robin_Watts | kens: Have you looked at the deltas ? | 14:45.28 |
| kens | How would that help ? | 14:45.40 |
| Robin_Watts | (actually, maybe you're not talking about the cluster again. I should shut up) | 14:45.51 |
| kens | As chrisl said, we don't test this configuration on the cluster | 14:45.56 |
| Robin_Watts | Then I should shut up. | 14:46.07 |
| kens | Aha! | 14:48.25 |
| | It doesn't work at least as far back as 9.0 | 14:48.34 |
| | Substitution is fine but not when creating PDF toutpu. | 14:48.47 |
| | Err, output. | 14:48.52 |
| | So I can probably 'fix' that to get the same behaviour easily | 14:49.42 |
| | Robin_Watts : OK how do I put my checkout back to the HEAD ? | 14:51.17 |
| Robin_Watts | git checkout master | 14:51.28 |
| kens | ah, master, right.... | 14:51.37 |
| Robin_Watts | HEAD = where you are :) | 14:51.47 |
| kens | was trying to use HEAD | 14:51.48 |
| | Yet Another Rebuild :-( | 14:53.16 |
| chrisl | So, I reckon pdfwrite needs the same logic for skipping the CDevProc in (at least) scan_cmap_text() as is in zchar_set_cache() | 15:00.24 |
| kens | That might work, yes. | 15:00.44 |
| | Right now I'm concentrating on not getting a crash | 15:00.54 |
| chrisl | Well, that would solve the crash - this seems to be one of those cases where pdfwrite needs to be "in sync" with other places | 15:01.56 |
| kens | Possibly. I'd like to understand why PS_accumulator is non-zero | 15:02.14 |
| | If it was 0 the old behaviour would hold | 15:02.40 |
| | This is so convoluted I'm not changing aythhing until I understyand it | 15:03.42 |
| chrisl | PS_accumulator is initialised to non-zero - it's in the template | 15:06.17 |
| kens | I know. | 15:06.24 |
| | Its only ever set to 0 when we install a type 3 charproc accumulator | 15:06.37 |
| chrisl | Which seems reversed logically...... | 15:07.17 |
| kens | thats what I was thinking. I assum e I had a good reasn | 15:07.40 |
| chrisl | Confusion, panic and horror? | 15:08.06 |
| kens | I can only assume we also accumulate PostScript and we only set it to 0 when accumularting a CharProc rather than 'PostScript' | 15:08.10 |
| | Could be for patterns and forms perhaps | 15:08.29 |
| chrisl | I'm not sure that has any influence here, though, it looks to me as though it was crash even in the PS_accumulator == false case | 15:09.06 |
| kens | No, because it falls thrtough tot he 'unregistered' error. | 15:10.13 |
| chrisl | Oh, okay. Actually, this isn't very "simple" after all, because the zchar_set_cache() logic uses the font dictionary - argh! | 15:12.41 |
| kens | Well I can get the crash to go away so I'm going to do that. | 15:13.02 |
| chrisl | So it will exit with an error? | 15:13.31 |
| kens | Yes, that's what it always did. | 15:13.46 |
| | At least, as far back as 9.0 | 15:13.58 |
| chrisl | Fair enough | 15:14.05 |
| kens | OK I see, I contracted a test when I modified this, and that wasn't legal, I'll just put it back in. | 15:15.09 |
| | OK that exits with an error. I'll commit that and then look at the CDevProc skipping | 15:17.17 |
| | chrisl I was correct about the CDevProc. If we don't execute it then the spacing goes haywire. | 15:32.46 |
| | All the glyphs end up on top of each other. | 15:32.58 |
| | I kind of wonder how this works when rendering. | 15:33.36 |
| chrisl | I think it would be better to run the CDevProc anyway. | 15:34.14 |
| kens | Its vital if pdfwrite is to get the correct answer. | 15:34.33 |
| | By not running hte CDevProc I can get a file out, and its sort of OK apart from all the CIDFont glyphs being on top of each otehr, which makes it hard to tell if they are a decent substitution. | 15:35.09 |
| chrisl | Okay, give me a few minutes, I'm just looking to see if we can retrieve the CID in zchar_set_cache() | 15:35.23 |
| kens | Looks like we're tackling it from different angles ;-) | 15:35.40 |
| | The substitution looks to be all over the place anyway, which might be the same problem. | 15:37.13 |
| | I have to say that looks like one of my comments in there.... | 15:41.34 |
| | Well, if I execute the CDevProc, I get better sp[acing, but the glyphs are still all wrong :-) | 15:42.43 |
| chrisl | Is that with pdfwrite or rendering? | 15:46.04 |
| kens | pdfwrite, sorry, the rendering is 'OK' | 15:46.15 |
| | THe font is a bit ugly but the glyph shape slook generally correct. | 15:46.28 |
| chrisl | pdfwrite shouldn't be embedding the substitute font, should it? | 15:46.58 |
| kens | It is if you execute teh CDevProc. | 15:47.26 |
| | It thinks its the real font. | 15:47.33 |
| | Going by the small amount of Latin text I cna follow, it looks like all the glyphs are out by 2. | 15:48.11 |
| chrisl | Is this using DroidSans or batang? | 15:48.58 |
| kens | DroidSans | 15:49.07 |
| | Using your shiny new substitution code. | 15:49.15 |
| chrisl | Can you try it with another font? I'm wondering if pdfwrite doesn't like the additional cmap format | 15:49.43 |
| kens | Example on p26 of that test file is a diagram labelled (in red) '6c' whcih after pdfwrite comes out as '4a' | 15:50.02 |
| | I'll try Batang. | 15:50.12 |
| | Duh, need to change the font name. | 15:52.14 |
| | Replaced Adobe-Korea1 with Batang. | 15:53.13 |
| | But I must have the Encoding really out, its very strange text. | 15:53.38 |
| | I guess Identity is not a good mapping. | 15:54.00 |
| | Any suggestions ? | 15:54.06 |
| | This is for Bug690320 | 15:54.18 |
| | 692320 | 15:54.29 |
| chrisl | Eh, surely you want a Korea1 ordering? | 15:55.08 |
| | batang includes Korean glyphs | 15:56.34 |
| kens | If you knwo a Korean ordering ? | 15:57.21 |
| | offhand. | 15:57.33 |
| chrisl | Korea1 | 15:57.47 |
| kens | OK one sec | 15:58.09 |
| | That looks 'better' | 15:58.49 |
| | More or less right in fact. | 15:58.57 |
| | Yes, the glyphs are correct. | 15:59.21 |
| chrisl | So, there's something that pdfwrite doesn't like about DroidSansFallback - oh great :-( | 15:59.33 |
| kens | Well, that looks like its my problem.... | 15:59.52 |
| chrisl | I'd assumed that pdfwrite wouldn't embed substituted fonts because, well, they're wrong | 16:00.24 |
| kens | interstingly, given that Acrobat is also using Batang, the output is not identical, the glyphs are lighter in our PDF file | 16:00.32 |
| | chrisl, it does for Latin fonts | 16:00.43 |
| | And if we execute the CDevProc, also for CIDFonts. | 16:01.00 |
| chrisl | That seems like the wrong behaviour, to me | 16:01.33 |
| kens | Won't disagree, but we have no easy way to tell if a font is substituted. | 16:02.15 |
| | Also, if you do have a decent substitute, you csan turn a PDF rfile with a missing font into a PDF file which is legal ;-) | 16:02.35 |
| kens | is AFK for a bit, I have a plumber here | 16:02.52 |
| | chrisl are you still looking at the CDevProc thing ? | 16:18.01 |
| chrisl | kens: yes | 16:18.46 |
| kens | OK thanks, I'll be back and forward a bit. | 16:18.58 |
| | Seg fault has gone away at least :-) | 16:19.24 |
| chrisl | I'm pretty sure I've got the CID for the substituted font so we can run the CDevProc properly | 16:19.34 |
| kens | That would be good. | 16:19.48 |
| | I can look at the DroidSans fallback seperately | 16:20.11 |
| chrisl | I've just lost the bug that inspired your change to skip it...... | 16:20.15 |
| kens | I don't remember :-( In fact I don't remembe rthe change ata ll.... | 16:20.36 |
| chrisl | I found it, I had it buried in a firefox tab from earlier | 16:21.01 |
| kens | Well I suppose I had a reason for doing it, I wonder what it was ;-) | 16:21.31 |
| chrisl | http://bugs.ghostscript.com/show_bug.cgi?id=690876 | 16:22.34 |
| kens | Wow, I had a lot to say about it. | 16:23.51 |
| | OK I guess you know more than I did back then about our PDF interpreter and TT substitution, I obvioously couldn't figure a way to reverse the mapping. | 16:27.16 |
| chrisl | Hmm, maybe not, I'm not getting good output :-( | 16:27.50 |
| kens | :-( | 16:28.05 |
| chrisl | Nobody else gets this job "right" either - I think the file is broken | 16:30.04 |
| kens | Which one is this ? The one I did the change for ? | 16:40.17 |
| chrisl | The one for #690876 | 16:40.34 |
| kens | Yes, that's the one. | 16:40.47 |
| | But 'Acrobat gets it right' :-( | 16:41.02 |
| chrisl | No not for me | 16:41.32 |
| kens | Really ? Let me look | 16:41.41 |
| chrisl | Acrobat gets it better than the png attached to the bug, but there's still a lot of glyphs clashing | 16:42.17 |
| kens | I guess hte question is 'waht's it supposed to look like' | 16:42.25 |
| | I do see some possible vertical collisions, is that what you mean ? | 16:42.57 |
| | I thought that might be deliberate. | 16:43.32 |
| chrisl | If you look at the line of glyphs under where it says "Carriage and Insurance Paid To" the glyphs run together and (it looks like) overwrite a few cases | 16:44.19 |
| kens | THey don't seem to for me. | 16:44.39 |
| | They are quite close though | 16:44.56 |
| chrisl | kens: Acrobat for me: http://www.ghostscript.com/~chrisl/2e-unc-mod.png | 16:47.04 |
| | current ghostscript: http://www.ghostscript.com/~chrisl/test001.png | 16:51.22 |
| | and my "in test" Ghostscript: http://www.ghostscript.com/~chrisl/test-new001.png | 16:51.52 |
| Robin_Watts | tor8: ping | 16:54.39 |
| tor8 | Robin_Watts: pong | 16:55.38 |
| Robin_Watts | I'm looking at reworking the store a bit. | 16:55.48 |
| | How would you feel about every "storable" object starting with a common structure | 16:56.21 |
| | (possibly just one pointer) | 16:56.27 |
| tor8 | void (*drop)(fz_context *ctx, void *ptr) ? | 16:56.56 |
| Robin_Watts | tor8: No. | 16:57.13 |
| tor8 | then please explain :) | 16:57.55 |
| Robin_Watts | Rather than pdf_store_find, we need to move to pdf_store_claim | 16:57.55 |
| | and pdf_store_release. | 16:58.03 |
| | so we never ditch an object while it's in use. | 16:58.50 |
| tor8 | right. | 16:58.59 |
| kens | chrisl that's not good, mine is better. | 16:59.08 |
| Robin_Watts | And if we search for an item on claim, I don't want to have to search again to release. | 16:59.30 |
| chrisl | kens: what version of Acrobat? | 16:59.43 |
| kens | 9.4 | 16:59.48 |
| Robin_Watts | hence I'd like to have the returned objects have a pointer to their position in the store within them. | 16:59.51 |
| tor8 | Robin_Watts: can't you look at the refs to find that out though? | 17:00.19 |
| henrys | yikes meeting time | 17:00.25 |
| chrisl | kens: same here. What font does yours say is in use? | 17:00.50 |
| kens | Hmm chrisl if I turn off all the enhanscements and zoom out its similar to yours | 17:00.56 |
| | Mine i using STSong-Light | 17:01.13 |
| Robin_Watts | tor8: Not trivially. | 17:01.24 |
| tor8 | in the xref I treat fz_obj's as weak references | 17:01.37 |
| kens | chrisl what zoom level did you use ? | 17:01.41 |
| tor8 | basically, don't flush them if the refcount > 1 (knowing that one of the ref counts is the xref's) | 17:02.05 |
| chrisl | kens: 150 dpi export to png | 17:02.08 |
| kens | One second then | 17:02.15 |
| mvrhel_laptop | Robin_Watts: did you ever review the results from the planar run that marcos did? I had not done that yet | 17:02.22 |
| tor8 | but I haven't thought through the store issues in detail. | 17:02.27 |
| Robin_Watts | mvrhel_laptop: No, sorry. | 17:02.31 |
| | tor8: I'm considering the thing that's stored to be the "key,val pair" | 17:03.04 |
| | hence the ref count of the val is not what I'm after. | 17:03.17 |
| henrys | There is going to be another huge review before planar - substituting the gray color space will change almost every pcl file. | 17:03.37 |
| Robin_Watts | henrys: it will? | 17:03.58 |
| mvrhel_laptop | what substitution? | 17:04.14 |
| Robin_Watts | What's changing ? | 17:04.16 |
| henrys | Robin_Watts:anything with text with be K not CMY | 17:04.38 |
| | s/with/will | 17:04.50 |
| | lots of files have text ;-) | 17:05.01 |
| Robin_Watts | Is that like a tagging thing ? | 17:05.22 |
| henrys | No, it is a change for PCL I should have out sometime this week. | 17:05.46 |
| Robin_Watts | I don't follow, but never mind. | 17:05.55 |
| | "before planar" - all the planar stuff is committed. | 17:06.10 |
| kens | chrisl in my directory on peeves is 0000002e.png my export from acrobat at 150 dpi | 17:06.42 |
| mvrhel_laptop | marcosw: in the test that you did, did you have the fast halftoning for color turned on? | 17:07.13 |
| henrys | Right now pcl uses an RGB indexed color space with 2 entries for text, the change will have it use DeviceGray - the graphics library can convert the latter to just K but the former it converts to CMY, make sense? | 17:07.19 |
| Robin_Watts | henrys: OK, thanks. | 17:08.02 |
| henrys | I didn't have much meeting wise. I will send out the agenda followup today. | 17:08.27 |
| | anybody else have meeting items? | 17:09.13 |
| chrisl | kens: well, I'm bemused - that's nothing like the output I get from Acrobat :-( | 17:09.25 |
| kens | chrisl that was 300 dpi, sorry | 17:09.35 |
| mvrhel_laptop | nothing from me. I am off to SLC tomorrow | 17:09.38 |
| kens | But its much better than your output | 17:09.42 |
| | No meeting stuff from me | 17:09.49 |
| marcosw | mvrhel_laptop: I'm checking, but I believe it was the default settings. | 17:10.02 |
| kens | chrisl I redid at 150 and its still much better | 17:10.05 |
| Robin_Watts | henrys: Nothing from me. | 17:10.08 |
| henrys | I do think the FAQ should clearly say this is a ghostscript faq then should have a bibliography of reference manuals | 17:10.20 |
| mvrhel_laptop | marcosw: ok, then the comparison is not too bad. | 17:10.35 |
| chrisl | kens: different file | 17:10.55 |
| henrys | alexcher? | 17:11.00 |
| tor8 | Robin_Watts: stored in the cache, or stored per object? | 17:11.06 |
| alexcher | yes | 17:11.06 |
| henrys | alexcher anything for the meeting? | 17:11.17 |
| kens | chrisl I'll get the reduced file. | 17:11.19 |
| mvrhel_laptop | marcosw: it would be nice to run it with the fast thresholding. do you know where to do that change? | 17:11.26 |
| ray_laptop | oops. Sorry I forgot to get on IRC. I'm checking the logs to see if I missed anything. | 17:11.43 |
| Robin_Watts | tor8: stored in the cache. | 17:11.54 |
| henrys | hi ray_laptop:anything for the meeting? Trying to conclude early. | 17:11.55 |
| kens | chrisl the reduced file looks like yours. | 17:11.58 |
| Robin_Watts | tor8: Let's postpone this until after the meeting ends. | 17:12.06 |
| kens | I wonder if that's the one where I edited teh widths ? I bet it is. | 17:12.21 |
| alexcher | DNS record for spectre.ghostscript.com is broken. Who maintains it? | 17:12.32 |
| ray_laptop | henrys: nothing for the rest, but I owe mvrhel_laptop a reply on VDP | 17:12.33 |
| kens | WHich is why its wrong, you should use the original | 17:12.35 |
| | chrisl did you catch that ? | 17:12.51 |
| marcosw | mvrhel_laptop: I'm sure I have it in an email, but it's faster if you remind me. | 17:12.52 |
| chrisl | kens: my new code matches Acrboat with the original file, too | 17:13.04 |
| kens | Right, then I would say it is correct. | 17:13.17 |
| mvrhel_laptop | marcosw: ok hold on | 17:13.19 |
| tor8 | Robin_Watts: okay. I'll pop out for dinner after the meeting. but in general I don't object to adding a fixed set of fields at the beginning of cachable objects. | 17:13.23 |
| kens | chrisl the reduced file has the /DW changed to 500 from 1000. | 17:13.34 |
| Robin_Watts | alexcher: See /var/cache/bind/ghostscript.com on casper | 17:13.35 |
| henrys | tor8, Robin_Watts:I do want to talk to you about the documentation. I'd like to get mupdf out there as a pdf based graphics library option, but I can't see that being possible without docs. | 17:13.39 |
| Robin_Watts | tor8: OK. I'll put something together and wave it at you after your dinner. ping me when you're back. | 17:14.00 |
| chrisl | kens: I want to try it with the old-old code to see if I can still see the breakage you were fixing | 17:14.07 |
| Robin_Watts | henrys: indeed. tor8 was going to approach sebras about it, right? | 17:14.16 |
| mvrhel_laptop | marcosw: line 67 in gxicolor.c change it to true | 17:14.44 |
| ray_laptop | alexcher: I get 'not found' can't find spectre.ghostscript.com: Non-existent domain | 17:14.45 |
| tor8 | henrys, Robin_Watts: I have sebras here now. he's not opposed to the idea, but may not have a lot of time. | 17:14.52 |
| kens | chrisl makes sense, I'm sure you will. I obviously did consider this as a solution, but didn't go far enough with it. With that in place pdfwrite works with substitute fonts. Not with DroidSans, but that's my problem to look at. | 17:15.13 |
| henrys | "have him here" in a cell or something? | 17:15.29 |
| sebras | tor8, henrys, Robin_Watts: no, I'm here. :) | 17:15.40 |
| tor8 | he's stolen my workstation! | 17:15.43 |
| chrisl | kens: I can't reproduce the original problem, it seems - I wonder if FAPI magically fixes it....... | 17:15.58 |
| kens | Interesting! | 17:16.06 |
| Robin_Watts | Has anyone ever seen sebras and tor8 at the same time? | 17:16.07 |
| henrys | ahh hah | 17:16.28 |
| mvrhel_laptop | hehe | 17:16.33 |
| kens | chrisl whichever way works, go with it. Its an improvement over what was there before. | 17:16.38 |
| henrys | so meeting adjourned for those that won't to go but I'll be sticking around for a bit. | 17:17.07 |
| kens | I'll be here ofr a bit longer | 17:17.18 |
| tor8 | Robin_Watts: rillian has, but he's not here to tell. | 17:17.29 |
| mvrhel_laptop | kens: do I need to send you an email about color conversion still for pdfwrite? | 17:17.48 |
| | or do you have everything you need (more or less) | 17:18.02 |
| kens | mvrhel_laptop : probably, if I only knew what I needed ;-) | 17:18.10 |
| Robin_Watts | spectre IN CNAME alexcher.dyndns-web.com. | 17:18.27 |
| kens | I think I need to see how to call the conversions for a single colour and a buffer of samples | 17:18.28 |
| mvrhel_laptop | ok, I will send you an email with that information | 17:18.41 |
| | so you can then just hook in and do it | 17:18.51 |
| kens | Thanks mvrhel_laptop | 17:19.11 |
| | One day.... | 17:19.20 |
| ray_laptop | kens: what do you think about the guy trying to ps2pdf a 1.2Gb file ? | 17:19.22 |
| kens | I suspect he's falling over the temp file limit of 2GB | 17:19.37 |
| | Probably he has compressed image data or something | 17:19.47 |
| | I will reply, I haven't had a cahcne yet | 17:19.56 |
| | I really don't want him to send me the file | 17:20.23 |
| ray_laptop | kens: so pdfwrite doesn't use the 64-bit file I/O ? | 17:21.08 |
| kens | Yes it does, but if you recall I tried to sort this out before, and didn't quite manage. | 17:21.28 |
| | There's an open enhancement request. | 17:21.34 |
| | However, I am not convinced this is a pdfwrite problem, the ioerrer in 'image' sounds like it might just as easily be an interpreter error. | 17:21.57 |
| ray_laptop | kens: right, that's what I was thinking. | 17:22.17 |
| kens | I will suggest he tries a rendering decvice before going further | 17:22.33 |
| ray_laptop | we should at least ask him to post the file somewhere we can get it | 17:22.35 |
| kens | I *really* don't want to download a 1.2Gb file | 17:22.50 |
| ray_laptop | kens: Even just the bbox device (at least the output won't be an issue) | 17:23.01 |
| kens | Yes, just to isolate the PS interpreter from the problem. | 17:23.19 |
| | ray_laptop : see bug #692290 | 17:23.36 |
| mvrhel_laptop | ray_laptop: let me know if you need me to look anymore at 692674. I am curious if we "fixed" the issue they are seeing | 17:23.58 |
| alexcher | I don't mind downloading 1.2G. It's faster than arguing with the user. | 17:24.21 |
| mvrhel_laptop | I am going to work on disabling the CRD cache construction now | 17:24.26 |
| | oh that reminds me | 17:24.30 |
| kens | alexcher : not for me.... | 17:24.34 |
| ray_laptop | mvrhel_laptop: I'm repeating the timings with UseFastColor this AM | 17:24.48 |
| Robin_Watts | alexcher: Did you get a chance to try the binary ps patch ? | 17:24.51 |
| kens | But I suspect it'll be 'confidential' | 17:24.51 |
| | ray_laptop : did you pick up the charpath fix in FAPI too ? Makes pdfwrite work as before . | 17:25.17 |
| mvrhel_laptop | kens: does pdfwrite ever do any CIE joint cache writing with the CRD? It did not appear to be from what I could see, but I thought I would double check with you | 17:25.19 |
| | joint cache usage that should say | 17:25.34 |
| alexcher | Robin_Watts: it doesn't work but I don't know the cause yet. | 17:25.36 |
| ray_laptop | kens: I saw 692290 -- I'd be surprised if a 1.2Gb PS file blew out the 4Gb temp file, but I supposed it is possible | 17:25.47 |
| kens | mvrhel_laptop : Possibly but I am not sure, what hapopens if we set -dUseCIEColor and tehn ask for a device space ? | 17:25.50 |
| Robin_Watts | alexcher: OK, let me know if you need anything from me (or if you want to give up and pass it back to me) | 17:26.08 |
| kens | ray_laptop : if it has one very large comrpessed image then that wouldn't be too big a suirprise | 17:26.09 |
| Robin_Watts | alexcher: Thanks for looking at it. | 17:26.18 |
| ray_laptop | kens: but we store the image data in the temp file in compressed form, don't we ? | 17:26.35 |
| mvrhel_laptop | in the graphics lib that option is ignored as we use the ICC profiles specified | 17:26.36 |
| | let me poke a bit at pdfwrite to understand what is going on | 17:26.56 |
| kens | ray_laptop : we store it *several* ways.... | 17:26.59 |
| | mvrhel_laptop : I don't know but something must convert the CIE colours back to device space when using PDF/A | 17:27.24 |
| | If you sue normal pdfwrite tit will just end up as an ICCBased space in the PDF. | 17:27.39 |
| ray_laptop | mvrhel_laptop: I can't imaging why pdfwrite would ever need the joint cache. It's not like it's going to emit a colorspace from it | 17:27.41 |
| kens | ray_laptop : If we have a CIE colour and are producing CMYK/RGB for PDF/A output ? | 17:28.08 |
| mvrhel_laptop | kens: what is the command line option the get PDF/A | 17:28.36 |
| kens | -dPDFA | 17:28.41 |
| | :-) | 17:28.44 |
| mvrhel_laptop | s/the/to/ | 17:28.59 |
| kens | You can ignore the fancy stuff, that won't produce a valid file, but it will do all the work | 17:29.00 |
| | Oh, you probably need to set -sProcessColorModel=/DeviceCMYK as well | 17:29.48 |
| | or /DeviceRGB of course | 17:29.54 |
| | and set -dUseCIEColor | 17:30.03 |
| ray_laptop | kens: PDF gets the colorspace (Cal*, ICCBased) directly doesn't it ? | 17:30.06 |
| kens | ray_laptop : you cna't use ICCBased spaces in PDF/A | 17:30.21 |
| | Ah wait, do I mean PDF/X | 17:30.39 |
| | There are too many flavours of PDF | 17:30.56 |
| mvrhel_laptop | ok and so what is the expectation with and without -dUseCIEColor? | 17:31.22 |
| | oh. I remember this now | 17:31.22 |
| | all the PS CIE color spaces are converted to V2 profiles for pdf output | 17:31.22 |
| | you cant have ICC in PDF/A? | 17:31.22 |
| | hehe | 17:31.22 |
| kens | I think PDF/A is OK, I must mean PDF/X | 17:31.38 |
| ray_laptop | kens: don't you use the CMM (link profile) to get RGB or CMYK from the ICCBased ? (not the joint caches and old color system) | 17:31.45 |
| mvrhel_laptop | this is what we are trying to figure out.... | 17:32.08 |
| kens | ray_laptop : I don't use anything I don't know how this is done right now. As far as I know it happens 'behind the scenes' | 17:32.09 |
| ray_laptop | PDF/X is the one that flattens the colors, iirc | 17:32.11 |
| mvrhel_laptop | I will dig into this a bit and see what is going on | 17:32.57 |
| kens | Yes, sorry -dPDFX -dUseCIEColor -sProcessColorModel=/DeviceRGB | 17:33.04 |
| mvrhel_laptop | ah ok | 17:33.09 |
| kens | The ps2pdf.htm doc has all the gubbins | 17:33.19 |
| mvrhel_laptop | ok cool | 17:33.26 |
| | and so in the above command line, a CMYK ICC or CMYK CIEDEFG or DeviceCMYK colors have to be converted AND the resulting PDF is stored as DeviceRGB? | 17:34.15 |
| kens | Actually it has to be DeviceCMYK, apparently DeviceRGB isn't allowed either | 17:34.40 |
| | But yes, only spaces valid in PDF 1.3 are premitted. | 17:34.52 |
| mvrhel_laptop | ok so switch all of that around | 17:34.53 |
| | 1.3 allows ICC | 17:35.02 |
| | doesnt it? | 17:35.11 |
| kens | Does it ? | 17:35.11 |
| mvrhel_laptop | I thought | 17:35.15 |
| kens | Well in that case I suppse we are OK. | 17:35.18 |
| | I'll get my 1.3 spec out | 17:35.34 |
| ray_laptop | kens: I thought there was a revision to PDF/X that allows DeviceRBG | 17:36.31 |
| kens | You can do it by specifying a DefaultRGB. But it seems we don't permit that. | 17:36.51 |
| mvrhel_laptop | kens: I remember one time long ago you sent me a chart with all of this | 17:37.18 |
| kens | I did ? My memory is getting worse with age.... | 17:37.29 |
| | There is no index entry for ICXbased in the PDF 1.3 spec. | 17:37.54 |
| mvrhel_laptop | hmm I though ICC was introduced in 1.4 | 17:38.11 |
| | 1.3 | 17:38.13 |
| kens | No, I see it in 1.34 | 17:38.20 |
| | 1.3 | 17:38.22 |
| | Its just hard to find. | 17:38.27 |
| mvrhel_laptop | ok | 17:38.42 |
| kens | Now to go back to the PDF/X spec | 17:38.59 |
| | OK well the only other condition is that we can write with PDF 1.2 conformance, and I should also point out that ps2write can't handle ICCBased spaces at all. | 17:40.23 |
| | ANd sets the conformance level to PDF 1.2 as a result. | 17:40.35 |
| mvrhel_laptop | ok then I can understand no ICC colors | 17:40.53 |
| | then things should be converted to DeviceXXXX | 17:41.11 |
| kens | Try setting CompatibilityLevel=1.2 | 17:41.12 |
| mvrhel_laptop | ok | 17:41.15 |
| kens | mvrhel_laptop : This is the bug I was looking at before, they are not converted. | 17:41.31 |
| ray_laptop | ISO 15930-7:2008: PDF/X-4, Colour-managed, CMYK, gray, RGB or spot colour data are supported, as are PDF transparency and optional content. A second conformance level named PDF/X-4p may be used when the ICC Profile in the output intent is externally supplied. | 17:41.38 |
| mvrhel_laptop | yes I remember we talked about this | 17:41.43 |
| kens | The code assumes that the ICCBased space is just a device space, and chooses on based on teh number of components | 17:41.50 |
| mvrhel_laptop | what would be nice is to at least convert the to devices ICC profile color space | 17:42.17 |
| kens | So a Lab profile is assumed to be RGB, and results in really bad output | 17:42.21 |
| mvrhel_laptop | so that they all go to a common color space | 17:42.26 |
| | yes | 17:42.28 |
| kens | mvrhel_laptop : yes, this is the reason I was asking about it :-) | 17:42.43 |
| | Anyway, the simple answer to your question appears to be that we *don't* use the joint cache, even when maybe we should ;-) | 17:43.05 |
| mvrhel_laptop | well it is just as well, we would not want to be using it as we move forward to use the ICC profile | 17:43.34 |
| kens | I agree completely. I want to move pdfwrite over to using the ICC based workflow. | 17:43.57 |
| mvrhel_laptop | ok. so I will get you a small write up on doing those conversions | 17:44.17 |
| kens | Among other things it will allow us to do PDF/X-1 which does restitrct to device spaces, and which we don't currenlty support. | 17:44.34 |
| mvrhel_laptop | ah yes | 17:44.48 |
| kens | mvrhel_laptop : THat sounds great, hoperfully it will be nice and easy :-) | 17:44.49 |
| mvrhel_laptop | it should be | 17:44.57 |
| kens | suspects that identifying all the places in pdfwrite will be a lot harder | 17:45.21 |
| mvrhel_laptop | yes. that will be the hard part. all the if then if then else if then etc etc | 17:45.42 |
| kens | Yes :-( | 17:45.52 |
| | I see Alex asked the user to supply the file, so I won't bother asking him to try a rendering device. | 17:46.16 |
| | THe large 1.2 Gb file that is | 17:46.24 |
| | TIme for me to go, goodnight all. | 17:48.01 |
| ray_laptop | mvrhel_laptop: do you want to discuss the VDP now ? | 18:01.26 |
| mvrhel_laptop | sure | 18:02.04 |
| ray_laptop | mvrhel_laptop: so we currently only have one (ancient, probably bit-rotted) device that does 'partial page' rendering, and that only when in clist mode. | 18:03.18 |
| | we _could_ make devices do this, but it requires that the device create the buf_device, paint the 'background' and then process the page. The plumbing for this is a bit different for page mode or clist mode, so it probably belongs in gdevprn (as an option) | 18:05.08 |
| Robin_Watts | (being nosey, what's a VDP?) | 18:05.47 |
| ray_laptop | mvrhel_laptop: the short answer is that we don't have it, but it wouldn't be too hard to allow for a prn_device param that would specify a raster file that we would use as a background image. | 18:06.23 |
| mvrhel_laptop | ok. that was my suspicion | 18:06.35 |
| ray_laptop | Robin_Watts: Variable Data Printing | 18:06.36 |
| Robin_Watts | Repeated printing onto the same page, effectively? OK. | 18:07.17 |
| ray_laptop | Robin_Watts: specifying a background image that files print on top of (instead of a blank page). | 18:07.18 |
| Robin_Watts | Is there any way we can hook the 'fillpage' thing for that ? | 18:07.46 |
| ray_laptop | the other thing we have to do is to make sure that 'fillpage' doesn't erase the background | 18:07.56 |
| | Robin_Watts: that's probably exactly where we would hook it | 18:08.24 |
| mvrhel_laptop | ray_laptop: do you know though how the variable data is usually specified in these applications? Is it just a data base of names for example or is there a standardized format for PDF VDP or are there a bunch of competing proprietary methods. I found a bit about this but not too much | 18:08.47 |
| | hehe especially with all the repeated fill pages that we have | 18:09.04 |
| | still not sure why we do that | 18:09.23 |
| ray_laptop | mvrhel_laptop: it's been a while since I looked at the methods | 18:09.30 |
| mvrhel_laptop | ok. no worries | 18:09.38 |
| | I have a paper I printed out that appears to discuss the different languages used | 18:10.01 |
| ray_laptop | mvrhel_laptop: do you have a link (so I don't have to find it) >? | 18:10.34 |
| mvrhel_laptop | it is on my home computer. I will post it on IRC when I go back home from the coffee shop | 18:10.56 |
| | it is a few years old | 18:11.12 |
| ray_laptop | there was a sort of 'standard' method for PS, and I think a different method for PDF -- I don't recall any 'standard' methods for PCL (or XPS). PCL probably uses some PJL hack | 18:12.38 |
| | PS has 'Form' types that gs supports, but not by caching the rendered form. | 18:15.21 |
| mvrhel_laptop | I think I have enough for this meeting. It was just in his notes as there being a need for editing the interpreter to implement this and the fact that our interpreter is written in PS that may be a headache. The part I am a bit fuzzy about is how the database is handled by the application. Really depends upon how the database of variable data is constructed. If there is/was a standard we... | 18:16.48 |
| | ...could readily support it | 18:16.50 |
| chrisl | ray_laptop: could you "erase" with a pattern color space? | 18:17.17 |
| mvrhel_laptop | It is not clear to me that much editing in the interpreter would be needed | 18:17.22 |
| | but it depends upon how it was all implemented | 18:17.32 |
| | I am surprised we have not gotten much push from anyone on VDP as it is or has been a big thing in the industry | 18:18.29 |
| chrisl | Oh, heck, I'm late - 'night all! | 18:18.39 |
| mvrhel_laptop | night | 18:18.42 |
| ray_laptop | mvrhel_laptop: it seems that the -dUseFastColor helps quite a bit for the 'server' mode of running gs. | 18:25.59 |
| mvrhel_laptop | great | 18:26.09 |
| | not regenerating those same links over and over | 18:26.37 |
| | wait | 18:26.41 |
| | you mean for the case where you are not stopping and starting? | 18:26.59 |
| ray_laptop | mvrhel_laptop: right | 18:27.10 |
| mvrhel_laptop | that seems suprising | 18:27.20 |
| | I would think it would generate the links one time and then we would be just doing interpolations of the source data (not losing time from generating the tables themselves) | 18:28.21 |
| | that is when not using -dUseFastColor in the server mode | 18:28.51 |
| | henrys: did you do any timing tests with PCL and -dUseFastColor? | 18:29.26 |
| ray_laptop | mvrhel_laptop: I haven't done profiles on the two yet. Just reporting the initial testing. I'm running with more jobs now (50 instead of 10) | 18:29.29 |
| | mvrhel_laptop: at one point the customer was running tests with 1000 jobs ! | 18:30.31 |
| mvrhel_laptop | wow | 18:30.52 |
| ray_laptop | mvrhel_laptop: OK. ignore the previous. In 'server' mode, UseFastColor has no effect. | 18:37.35 |
| mvrhel_laptop | ok. good | 18:37.44 |
| henrys | mvrhel_laptop:no actually I forgot I'll do a quick check now. | 18:37.54 |
| | Robin_Watts:where's our regression windows box. | 18:38.13 |
| | ? | 18:38.16 |
| mvrhel_laptop | ray_laptop: but in the non-server mode it has an effect | 18:38.19 |
| Robin_Watts | henrys: Not connected at the moment, because I haven't sorted out making it only run non-banding. | 18:39.10 |
| ray_laptop_ | mvrhel_laptop: so ignore all comments until I get it sorted out. | 18:39.55 |
| mvrhel_laptop | hehe ok | 18:39.59 |
| Robin_Watts | And I want to make it run under msys rather than cygwin. | 18:40.14 |
| ray_laptop_ | mvrhel_laptop: I don't see any performance differences with -dUseFastColor so I am double checking. | 18:40.55 |
| mvrhel_laptop | hmm | 18:41.02 |
| henrys | mvrhel_laptop:It would be useful (at least for me) to have -ZC print out profile information - loading etc. it doesn't need to be verbose. | 18:43.23 |
| mvrhel_laptop | yes. | 18:43.58 |
| Robin_Watts | We no longer need to shoehorn things into 1 letter flags. | 18:44.29 |
| mvrhel_laptop | oh | 18:44.34 |
| | really? | 18:44.36 |
| ray_laptop | henrys: usually upper case output is more verbose than lowercase | 18:44.37 |
| | I also suggest a long option for profile related debugging messages | 18:45.09 |
| mvrhel_laptop | Robin_Watts: please elaborate | 18:45.09 |
| Robin_Watts | (i.e. if you can usefully have an option that's more verbose, but you are worried about not having enough flags, don't be). | 18:45.28 |
| ray_laptop | Robin_Watts: "fixed" the options list to allow for long option names a while ago | 18:45.31 |
| Robin_Watts | mvrhel_laptop: I reworked the options. | 18:45.38 |
| mvrhel_laptop | hmm I missed that one somehow | 18:45.51 |
| | so what do I need to do if I want an icc and an ICC option | 18:46.04 |
| Robin_Watts | mvrhel: Do gxwin32c.exe --debug | 18:46.19 |
| henrys | -Zc or a long option is fine for me. Just like to be able to quickly see what profiles are in play. | 18:47.03 |
| ray_laptop | Robin_Watts: I see "No debug flags supported in release builds" | 18:47.53 |
| Robin_Watts | ray_laptop: And your point is? | 18:48.10 |
| ray_laptop | Robin_Watts: but some of the options do work in release builds. | 18:48.15 |
| Robin_Watts | ray_laptop: Really? Bah. | 18:48.44 |
| | mvrhel_laptop: Look at gs/base/gdbflags.h | 18:49.02 |
| ray_laptop | Robin_Watts: and some flags require special build flags | 18:49.37 |
| Robin_Watts | ray_laptop: The 'long form' mapping only happens in debug builds. | 18:50.00 |
| ray_laptop | Robin_Watts: OK, I guess I can live with that as long as the short form still works | 18:50.26 |
| mvrhel_laptop | ok. I will look this all over later this week. writing up a how-to color convert for ken right now | 18:50.30 |
| ray_laptop | (and it appears to) | 18:50.33 |
| Robin_Watts | mvrhel_laptop: You just add a new line (or change one of the existing UNUSED ones) to that file. | 18:50.51 |
| | and then instead of using if_debug('x') or whatever, you use if_debug(gs_debug_flag_WHATEVER) | 18:51.52 |
| | (actually, it's still set to 127 flags only, but that's just a define) | 18:52.26 |
| | where WHATEVER is the long name option you pick. | 18:52.38 |
| mvrhel_laptop | hmm | 18:53.02 |
| | and how does the if_debug# call work? | 18:53.29 |
| | of | 18:53.43 |
| | oh | 18:53.45 |
| | sorry | 18:53.46 |
| | hehe | 18:53.48 |
| | need to read before I type | 18:53.52 |
| | ok. I will try this later this week | 18:54.20 |
| ray_laptop | mvrhel_laptop: if_debug* simply passes the first argument to gs_debug_c which is an 'int'. the gs_debug_flag_WHATEVER is also a valid int (as is 'x') | 18:57.03 |
| mvrhel_laptop | gotcha | 18:57.17 |
| ray_laptop | mvrhel_laptop: the nice thing is that gs_debug_c now works from a table so that 'C' doesn't automatically imply 'c' as it used to. There are explicit 'implies' fields in the table | 19:00.00 |
| | actually it is 'implied_by' so (for example) 'a' has 'A' given as its 'implied_by' entry, but 'c' has 0 so that 'C' doesn't automatically imply 'c' | 19:02.08 |
| | all in all a clever, and clean (particularly for gs) implementation, and quite versatile. Kudos to Robin_Watts ! | 19:03.12 |
| mvrhel_laptop | is it possible to have multiple implies? | 19:07.42 |
| | c implies C and icc? | 19:07.51 |
| | for example | 19:07.56 |
| Robin_Watts | yes. | 19:08.38 |
| | Every flag can only be implied by 1 thing though. | 19:08.56 |
| ray_laptop | mvrhel_laptop: the field is 'implied_by' so you can have 'C' imply multiple flags | 19:08.59 |
| | so if you have a gs_debug_flag_ICC it could be implied by 'C' and 'c' could also be impled by 'C' | 19:10.04 |
| mvrhel_laptop | where is FLAG defined | 19:10.39 |
| ray_laptop | mvrhel_laptop: base/gdebug.h | 19:11.22 |
| | (mostly) | 19:11.27 |
| mvrhel_laptop | ah ok | 19:12.05 |
| Robin_Watts | Look at the sausages, not the way they are made! :) | 19:12.50 |
| mvrhel_laptop | hehe | 19:12.59 |
| henrys | hates it when the regression test doesn't show files that should change. | 19:13.02 |
| ray_laptop | in my praise to Robin_Watts, I did qualify 'clean' by "for gs" ;-) | 19:15.57 |
| | mvrhel_laptop: also see base/gsmisc.c for the other (important) #define for FLAG | 19:17.52 |
| Robin_Watts | It's intended to be 'data driven'. Just change the (hopefully self-explanatory) header, and it 'just works'. | 19:19.28 |
| mvrhel_laptop | ok. doc sent off to ken | 19:33.20 |
| | now back to stopping the crd cache creation | 19:33.38 |
| | ray_laptop: so still no timing diffs? | 19:33.48 |
| tor8 | Robin_Watts: back | 19:34.45 |
| Robin_Watts | tor8: still bashing. | 19:34.56 |
| tor8 | Robin_Watts: okay, I'll go hide for a bit longer then :) | 19:35.09 |
| ray_laptop | mvrhel_laptop: no, connection here (coffee shop) is too bad -- I keep dropping. I'll pick it up when I get back to the office (or someplace with a better connection) | 19:35.19 |
| Robin_Watts | Do you ever expect us to put inbuilt colorspaces into the store? | 19:35.28 |
| | Things like fz_devicegray | 19:35.36 |
| mvrhel_laptop | ok no problem just curious | 19:35.55 |
| | bbiaw | 19:38.51 |
| henrys | bbiab | 19:52.24 |
| sebras | Robin_Watts: tor8 says no. | 22:05.25 |
| | Forward 1 day (to 2011/12/14)>>> | |
IRC Logs
