| | <<<Back 1 day (to 2011/12/06) | 2011/12/07 |
| Robin_Watts | bbhoss: First off, we can't hope to comment without a command line and the file you were processing. | 00:24.51 |
| | bbhoss: Secondly, asking us about 8.71 isn't going to really get a useful response, as it's quite old now. | 00:25.20 |
| bbhoss | I figured that, it's what is in the apt repo for a LPT release | 00:25.34 |
| Robin_Watts | Try again with 9.04 (or the head from the git repo). | 00:25.39 |
| bbhoss | it appears though that for some reason the file that I am trying to convert doesn't exist when I try to call gs on it, so it doesn't even seem to be a GS issue | 00:26.21 |
| | I was running with -q, so I wasn't seeing all of the errors | 00:26.39 |
| | Thanks for the help though Robin_Watts | 00:32.09 |
| Robin_Watts | np. | 00:33.53 |
| mvrhel | hmm so it does appear that we are creating the CRD portion of the joint CIE cache at start up. I need to get that all disabled | 00:55.54 |
| | thought I did that long ago | 00:56.00 |
| | I wonder though if this thing is used at all in pdfwrite when we have a -dUseCIEColor or some special PDF flavor for output | 00:57.07 |
| kens | Robin_Watts : your fix for partial path clipping seems to have made a pdfwrite problem go away in the cluster runs. | 09:25.47 |
| | Err, 'partial fix' not 'partial path'... | 09:26.20 |
| Robin_Watts | Right. | 09:41.47 |
| | The bug was showing up with a pdfwritten file. | 09:42.06 |
| kens | Sounds like it was the same file, thanks for fixing it :-) | 09:42.22 |
| Robin_Watts | no worries. | 09:42.29 |
| mupdfuser | Hi! Someone here who likes to give me a hint to a mupdf (pdfdraw) question? | 10:54.15 |
| tor8 | we won't know until you actually ask a question. | 11:10.06 |
| mupdfuser | Your right - forget that silly first question ;-) Scenario: Simple PDF with just a text, no background, will be rendered as transparent png via pdfdraw(antialiased). As long as the text is black, everything looks fine. But if make the text in the PDF eg. red and examine the rendered PNG, i see the alpha-steps containing black steps, though still moving to full transparency. If id do the same step with a gs call, only the red co | 11:18.14 |
| tor8 | you mean -a for "save alpha channel" (rather than antialiasing, which is on by default)? | 11:21.19 |
| mupdfuser | Yes! | 11:22.08 |
| tor8 | mupdfuser: I think I know the problem... we're using premultiplied alpha internally, but the png writing code doesn't convert it to non-premultiplied alpha. | 11:22.48 |
| | let me see if I can cook up a quick patch | 11:23.00 |
| mupdfuser | That would be brilliant! I already had a look into the sources but did not get much more to know than the fact, that i never learned to read or even write c-code ;-) | 11:25.03 |
| tor8 | mupdfuser: try http://ghostscript.com/~tor/stuff/premul.patch | 11:32.44 |
| mupdfuser | DUDE! | 11:50.59 |
| | That did it! | 11:51.05 |
| | I had a look in two of the three files you patched :-) Still i understand nothing :-) This is great news, the rendering looks much better than the gs version and is faster too. Will this patch go into the main source or will i have to try to apply it again for future releases? | 11:55.33 |
| | One small bug i see now - some little noise at the top of the rendered png occurs. not in all situations though... i will upload an example.... | 12:21.10 |
| tor8 | it'll make it into the main source soon | 12:21.46 |
| mupdfuser | Great! The noise example: | 12:25.15 |
| | https://anonfiles.com/cdn/1323260633566.pdf | 12:25.18 |
| | https://anonfiles.com/cdn/1323260647298.png | 12:25.22 |
| tor8 | mupdfuser: how did you create that png? | 12:32.56 |
| | I can't reproduce with pdfdraw | 12:34.40 |
| mupdfuser | It as the latest Trunk with your patch using "pdfdraw -b 8 -a -o 1323260647298.png 1323260633566.pdf" Maybe i broke something? I could get the current trunk and apply the patch again.... | 12:35.45 |
| | Sorry - i applied your patch to a trunk a few days old.... | 12:37.06 |
| sebras | tor8: I saved mupdfusers files for later potential inclusion in insane testing... | 12:37.09 |
| tor8 | mupdfuser: I can't reproduce with trunk + the patch I sent you | 12:38.12 |
| | looking at the raw data written (in uncompressed PAM format) I don't see any garbage | 12:38.31 |
| | maybe it's your image viewer (as unlikely as that is) | 12:38.44 |
| mupdfuser | Don't think so, different viewers show exactly the same noise. I will get the current trunk, apply the patch, compile and test again.... | 12:39.43 |
| | Compiling... | 12:54.08 |
| | Fresh trunk + patch solved the noise problem. Sorry for the trouble and thank you very, very much! Did not expect such great and fast help here. Thumbs up! | 13:03.43 |
| kens | Robin_Watts : you there ? | 14:02.57 |
| | ping tor8 | 14:06.07 |
| tor8 | hi kens | 14:06.18 |
| kens | Does MuPDF support CCITT compressed images ? | 14:06.34 |
| tor8 | kens: it should | 14:07.08 |
| kens | Ah wait, I see a broken PDF I think | 14:07.10 |
| tor8 | kens: wontshow.zip? | 14:07.21 |
| Robin_Watts | kens: sorry, yes. | 14:07.31 |
| kens | Just in on support from Raed, a file which 'opens bl;ank' | 14:07.32 |
| | tor8 Yes that one | 14:07.38 |
| tor8 | kens: let me take a look | 14:07.45 |
| kens | Robin_Watts : on stack overflow someone pointing out that our dox in make.htm doesn't mention the .vcproj files. We should update that | 14:08.07 |
| | tor8 I see the file is odd. | 14:08.18 |
| | It has : | 14:08.26 |
| | BT | 14:08.26 |
| | ET | 14:08.28 |
| | But what I think is the problem is the 'Qendstream' | 14:08.41 |
| | No white space | 14:08.52 |
| Robin_Watts | http://www.youtube.com/watch?v=w68qZ8JvBds | 14:09.28 |
| tor8 | kens: that shouldn't matter to mupdf. | 14:09.49 |
| kens | Ah, what Raed doens't mention is that although GS opens the file it warns 'Some elements of Mask array are not integers' | 14:09.49 |
| tor8 | it'll hit an 'end-of-file' instead and get the token out anyway | 14:10.05 |
| kens | Ooh, produced by one of our customers :-( | 14:10.17 |
| | "/Mask [0.8 1]" | 14:10.45 |
| tor8 | <page number="1"> | 14:10.47 |
| | <fill_image alpha="1" matrix="576 0 0 792 0 0" /> | 14:10.48 |
| | </page> | 14:10.48 |
| | yeah, that Mask is the culprit | 14:11.32 |
| kens | Thought it might be | 14:11.41 |
| tor8 | if I nuke the /Mask it shows up fine | 14:11.56 |
| kens | No idea if pdfwrite produced the file, though I suspect not | 14:12.02 |
| tor8 | we could very well have a bug in color keyed masking in mupdf | 14:12.34 |
| | it's a feature that hasn't been tested very extensively | 14:12.46 |
| kens | GS says its not valid, so I suspect its simply that we go one way MuPDF goes the other | 14:13.01 |
| | p 351 of the PDF reference (1.7) says that the array memebers must be integers | 14:14.07 |
| | In the range 0-2^BitsperComponent -1 | 14:14.30 |
| tor8 | kens: yeah, so someone hasn't read the spec and treats them as actual floating point color values instead | 14:15.15 |
| | if I round instead of truncate the numbers it shows up as expected | 14:15.34 |
| kens | Looks like GS just junks it, maybe MuPDF is trying to use it ? | 14:15.35 |
| | Fair enough, I'll leave it with you :-) | 14:15.50 |
| tor8 | since I end up with a color mask of [0 1] from that output, and just mask everything :) | 14:16.02 |
| | I think junking it is probably a better idea | 14:16.17 |
| | adding an odd 'round' there for one file is too hacky of a solution | 14:16.41 |
| kens | I think that may be 'correct', but I think that you are right, if its not valid, we can't and shouldn't trust it | 14:16.41 |
| | As always Acrobat doesn't complain. Since he'd tried GS you might have thought he would have realised the file is bogus. | 14:17.41 |
| tor8 | it says /Producer (activePDF Toolkit \(www.activepdf.com\)) | 14:19.09 |
| kens | Yeah that's what worries me | 14:19.23 |
| Robin_Watts | What is the Mask array specified as ? | 14:19.42 |
| tor8 | and the date is from 2003 | 14:19.45 |
| | Robin_Watts: /Mask [0.8 1] | 14:19.53 |
| kens | Robin_Watts : its an array | 14:19.56 |
| | That may predate our involvement though | 14:20.09 |
| | I like the YouTube video :-) | 14:20.26 |
| Robin_Watts | tor8: What's the harm in rounding ? | 14:21.24 |
| tor8 | Robin_Watts: fz_to_int always truncates everywhere else | 14:21.47 |
| Robin_Watts | I could imagine someone putting 0.9999999 out, and being justifiably annoyed that we didn't treat it as 1. | 14:21.59 |
| tor8 | though I guess that shouldn't really matter | 14:22.05 |
| kens | Robin_Watts : its contra the spec which says they must be ints | 14:22.16 |
| tor8 | let me change fz_to_int to round and sane it all | 14:22.20 |
| Robin_Watts | kens: right, but I could imagine people using floats everywhere and hence missing the mark a bit due to rounding. | 14:22.52 |
| kens | I'm just saying that when you use the wrong data type, all bets are off :-) | 14:23.18 |
| | I tjhink throwing the Mask away is hte best thing to do. If we are bothered I'm sure we can construct a (not black and white) image and see what Acrobat really does | 14:24.18 |
| Robin_Watts | kens: Just change the 0.8 to 0.4 and load the existing image into acrobat. | 14:25.00 |
| | s/image/file/ | 14:25.07 |
| | If it appears blank, then acrobat is rounding. | 14:25.14 |
| kens | OK, what happens ? | 14:25.14 |
| | Will try | 14:25.24 |
| Robin_Watts | I haven't got the file :) | 14:25.26 |
| | BT man arrived this morning. Was here for 2 minutes, confirmed it was an exchange fault, and then buggered off. | 14:25.53 |
| kens | Well that was helpful... | 14:26.03 |
| Robin_Watts | Supposedly he's reset it at the exchange and it should be better within 20mins-2 hours. | 14:26.20 |
| | Not yet :( | 14:26.22 |
| kens | CHanging Mask to 0.4 makes no difference in Acrobat | 14:26.30 |
| | SO I suspect its ignoring the broken data. | 14:26.50 |
| Robin_Watts | yeah. | 14:26.54 |
| | tor8: ping | 16:15.43 |
| tor8 | Robin_Watts: the new raed mail? | 16:15.53 |
| Robin_Watts | yeah. | 16:15.57 |
| kens | He's sure sending a lot, as Ray said | 16:16.10 |
| Robin_Watts | Looks like it's in fz_draw_begin_tile | 16:16.11 |
| tor8 | Robin_Watts: possibly or probably a borked bbox in a tiling pattern | 16:16.26 |
| | not sure if I ever implemented the 'run it through the bbox device first to get an accurate bbox' fix I was thinking about | 16:16.51 |
| Robin_Watts | It *is* in fz_draw_begin_tile - I have it stopped in the debugger. | 16:16.52 |
| tor8 | Robin_Watts: doesn't look like I do... | 16:18.18 |
| | try undef'ing TILE in pdf_interpret.c | 16:18.36 |
| Robin_Watts | in fz_draw_begin_tile, can we restrict the size of the tile to be the size of dev->dest ? | 16:19.33 |
| | undefining TILE works. | 16:21.09 |
| tor8 | Robin_Watts: there is code to try to figure out if a tile is only used once | 16:22.15 |
| | which I thought would catch most of these cases | 16:22.23 |
| Robin_Watts | but in general, why would we ever want to allow a tile that's bigger than dev->dest ? | 16:22.39 |
| tor8 | but if it's a huge tile of which you can see the corners only, the dev->dest size hack won't work (since you'll need data from all four corners) | 16:23.05 |
| Robin_Watts | tor8: right. | 16:23.40 |
| tor8 | we should probably just decide on a limit, if the tile is too big, don't use the begin/end tile (or buffer it in a display list and repeat in draw_tile) | 16:23.50 |
| Robin_Watts | but limiting the bounds of the tile to the bounds of dest won't hurt. | 16:23.58 |
| tor8 | consider the case where the tile is huge, but positioned so that the bottom 10% are visible on the top half of the page, and the top 10% are visible on the bottom half of the page | 16:26.02 |
| | so you see the bottom of one tile instance, and the top of another tile instance | 16:26.28 |
| Robin_Watts | Right. | 16:26.38 |
| | So the code I have in mind says: "If dev->dest is entirely contained in the bbox, then bbox = bbox of dev->dest" | 16:27.09 |
| | It won't catch every case, but it'll catch a lot of useful ones. | 16:28.40 |
| tor8 | Robin_Watts: we already have that test :) and disable tiling if it passes | 16:29.37 |
| Robin_Watts | So... why is my new code getting hit then? :) | 16:30.07 |
| tor8 | ifdef TILE? | 16:30.16 |
| | well, strictly speaking the test we have tests if the tile is only visible once | 16:30.35 |
| | which should cover the case you're talking about for the places where one huge tile completely covers the page | 16:30.58 |
| | brb | 16:31.53 |
| Robin_Watts | ok, my fix solves it. So why is it needed.... | 16:32.58 |
| | if (bbox.x0 <= dev->dest->x && bbox.x1 >= dev->dest->x + dev->dest->w && | 16:33.09 |
| | bbox.y0 <= dev->dest->y && bbox.y1 >= dev->dest->y + dev->dest->h) { | 16:33.11 |
| | bbox.x0 = dev->dest->x; | 16:33.13 |
| | bbox.y0 = dev->dest->y; | 16:33.14 |
| | bbox.x1 = dev->dest->x + dev->dest->w; | 16:33.16 |
| | bbox.y1 = dev->dest->y + dev->dest->h; | 16:33.17 |
| | } | 16:33.19 |
| | (in fz_draw_begin_tile) | 16:33.20 |
| | tor8: I can't see the code that tests for a tile only covering the page once. | 16:39.09 |
| | Ah: if ((x1 - x0) * (y1 - y0) > 1) | 16:40.13 |
| | Right. That test passes because of rounding issues. | 16:47.20 |
| | x0 is floorf(-0.0000001/815) = -1 | 16:48.02 |
| kens | Robin_Watts : Kindle Fire due for release in UK Jan 2012 (rumour) | 16:50.56 |
| Robin_Watts | kens: Don't want a fire. | 16:51.13 |
| kens | Oh, which version do you have ? | 16:51.25 |
| Robin_Watts | I have the kindle touch. | 16:51.35 |
| kens | Ah. | 16:51.39 |
| Robin_Watts | Kindle fire is the non-e-ink tablet. | 16:51.43 |
| kens | Too many variations with the same name :-( | 16:52.03 |
| Robin_Watts | It's an android tablet where amazon have attempted to lock it down to their own walled garden. | 16:52.22 |
| kens | ApCheap Apple clone :-( | 16:52.38 |
| mvrhel_laptop | kens: thanks for the feedback on jaws and also on the color stuff with pdfwrite | 16:55.11 |
| Robin_Watts | Indeed. It's a great price, but the locked down nature makes it worth avoiding. | 16:55.34 |
| kens | No problem. I'll be interested if you can find a method to do away with teh ICC profile initialisation stuff | 16:55.41 |
| mvrhel_laptop | Kindle fire is actually pretty fun. we have one and watch net flix, browse the web, read books. it is ok for the price | 16:56.01 |
| kens | For Evil Geniuses everywhere: | 16:56.01 |
| | http://www.firebox.com/product/4893/Project-Utopia | 16:56.01 |
| mvrhel_laptop | isnt that from some James Bond movie? | 16:56.47 |
| kens | Dr No I believe :-) | 16:56.57 |
| mvrhel_laptop | ok | 16:57.02 |
| Robin_Watts | mvrhel_laptop: But no android marketplace access, right? | 16:58.27 |
| mvrhel_laptop | I don't know. I have not really played with it too much except to watch a movie once and browse the web :) | 16:59.00 |
| kens | I believe the marketplace is specifically *not* available | 16:59.15 |
| | All your money are belong to Amazon | 16:59.45 |
| mvrhel_laptop | I am able to watch movies on netflix and check out books from the library | 17:00.38 |
| kens | 5pm Pizza time! Goodnight all | 17:00.42 |
| mvrhel_laptop | this is interesting | 17:01.01 |
| | http://www.pcworld.com/article/244474/how_to_install_the_android_market_on_your_kindle_fire.html | 17:01.03 |
| | looks a bit risky though | 17:01.29 |
| | chrisl: thanks also for the comments on jaws | 17:02.54 |
| chrisl | mvrhel_laptop: not a problem, I hope it's useful - I'll try to give you a bit more before the visit | 17:07.36 |
| mvrhel_laptop | ok great. thanks | 17:07.49 |
| Robin_Watts | tor8: ping | 17:24.25 |
| tor8 | Robin_Watts: yes? | 17:24.40 |
| Robin_Watts | The test for 'single tiled'... | 17:24.54 |
| | We could adjust the calculation of x0 etc slightly. | 17:25.22 |
| tor8 | right, rounding errors | 17:25.23 |
| Robin_Watts | x0 = floorf(area.x0 / pat->xstep + EPSILON) | 17:25.43 |
| | where EPSILON is anything < 1/256 | 17:25.53 |
| tor8 | yeah | 17:26.16 |
| Robin_Watts | (i.e. 'too small to see even with antialiasing') | 17:26.17 |
| | If you're happy for that as a fix, I'll give it a go. | 17:26.48 |
| tor8 | go ahead | 17:26.54 |
| | I got a nasty cold... :( | 17:27.09 |
| Robin_Watts | long haul flights :( | 17:27.31 |
| tor8 | stupid airports too! | 17:28.42 |
| Robin_Watts | BT are not only useless, they are cheeky bastards too. | 17:44.25 |
| mvrhel_laptop | I am fighting a cold too | 17:44.47 |
| Robin_Watts | They come round, confirm that they can indeed reproduce the fault I'm complaining about and that the fault is at the exchange. | 17:45.06 |
| | Engineer leaves to go to exchange to fix it, DOESN'T fix it, and then leaves a note on the system saying that "no fault was found", so it's a chargable visit. | 17:45.42 |
| mvrhel_laptop | thats insane | 17:47.13 |
| | they seem to lose sight of what the purpose of the visit was, which was to fix the problem | 17:47.57 |
| Robin_Watts | If it really was a fault in my house (which it isn't), and they turned up and fixed it, then I'd not (really) begrudge paying them to fix it. | 17:49.23 |
| | but I'm damned if I'm paying them to NOT fix a problem that's their fault anyway. | 17:49.44 |
| mvrhel_laptop | hehe | 17:50.10 |
| | yes | 17:50.13 |
| Robin_Watts | tor8: commit pushed. | 18:10.46 |
| | The latest mail from Raed (text appears corrupted using MuPDF)... can someone else run that file through gs please? | 18:28.41 |
| ray_laptop | I'm thinking that for mem based clist printers (as cust 532) it might be nice to have a hook to switch compress the memfile even when we aren't writing the memfile at the time. So that the alloc hook can detect memory getting tight, and make a call to switch to compressing (which will be ignored if we are already compressing). | 18:29.04 |
| Robin_Watts | He says it appears OK in gs and Acrobat, but in my tests it appears OK in Acrobat, but not gs. | 18:29.08 |
| ray_laptop | but the plumbing to set that hook might be "tricky" | 18:29.40 |
| | Robin_Watts: I'll try with gs... just a mo' | 18:30.04 |
| Robin_Watts | ray_laptop: So you'd have to cope with having written X bytes to the buffer, and then being told "oops, they should have been compressed" | 18:30.18 |
| chrisl | Robin_Watts: I changed Ghostscript's handling of out of spec symbolic TTFs recently, so it might be a problem with that change...... | 18:30.20 |
| ray_laptop | Robin_Watts: it already "switches" to compressing dynamically | 18:31.00 |
| Robin_Watts | If I resave the file from Acrobat and try and open that, gs gives me loads of warnings about 'Can't find CID font "Arial"' etc and still fails. | 18:31.16 |
| chrisl | Robin_Watts: I get that with the file as he sent it - it's a missing CIDFont | 18:32.42 |
| ray_laptop | Robin_Watts: that file was one we'd seen previously. I think it needs special settings for the cidfmap. Chris would have handled that. | 18:32.55 |
| Robin_Watts | yes, but I get it repeatedly after I save it out of Acrobat. | 18:33.08 |
| | right. MuPDF gets all the glyphs wrong. | 18:33.37 |
| ray_laptop | I get the messages from the original file from Raed: | 18:34.06 |
| chrisl | Well, with a substituted CIDFont, there's no certainty of it working - that's life | 18:34.07 |
| ray_laptop | Can't find CID font "Arial". | 18:34.08 |
| | Substituting CID font /Adobe-Identity for /Arial, see doc/Use.htm#CIDFontSubstitution. | 18:34.09 |
| | The substitute CID font "Adobe-Identity" is not provided either. Will continue, but content may be missing. | 18:34.11 |
| | **** Warning: can't process font stream, loading font by the name. | 18:34.12 |
| Robin_Watts | ray_laptop: Right. Me too. | 18:34.19 |
| | And I get nothing output at all. | 18:34.27 |
| | (and unbalanced q/Q) | 18:34.37 |
| | (or rather, I get a blank page output) | 18:34.51 |
| ray_laptop | Robin_Watts: me too. too many q's | 18:35.01 |
| chrisl | Yes, because Ghostscript now skips out of content streams that error | 18:35.18 |
| | The hint is in: "Will continue, but content may be missing." | 18:35.52 |
| Robin_Watts | chrisl: Is that a post 9.04 change ? | 18:36.22 |
| chrisl | No, I don't think so | 18:36.48 |
| Robin_Watts | So I'm confused by his claim that it works in ghostscript 9.04 | 18:37.04 |
| ray_laptop | I get the same errors (and blank page) from 9.04 | 18:37.07 |
| Robin_Watts | oh, he says GS 9.0 | 18:37.17 |
| chrisl | Robin_Watts: Raed will have a substitute font defined in his cidfmap file | 18:37.27 |
| ray_laptop | have to run an errand. bbiab | 18:37.59 |
| Robin_Watts | Right, but that won't stop it bailing/baling because of q/Q, right ? | 18:38.06 |
| | So how is Acrobat coping with it? | 18:38.29 |
| ray_laptop | Robin_Watts: AFAIK, q/Q problems are warnings only | 18:38.32 |
| Robin_Watts | Ah, sorry, I misunderstood what chrisl was saying. | 18:38.49 |
| ray_laptop | we ignore the imbalance and continue. It really only shows up after the page is done | 18:38.58 |
| Robin_Watts | OK, so the question is, how is Acrobat coping with this then? | 18:39.23 |
| ray_laptop | too many Q's we spot right away | 18:39.23 |
| chrisl | The file doesn't have unbalanced q/Q, but we'll end up missing a Q because we give up part way through a content stream | 18:39.42 |
| ray_laptop | Adobe obviously implicitly knows what to do with Arial CIDFont | 18:39.50 |
| Robin_Watts | Does it have magic in there to make a CID map? | 18:39.56 |
| chrisl | Acrobat? Yes, it does something undocumented to substitute CIDFonts | 18:40.27 |
| ray_laptop | if there is a ToUnicode entry, then it can substitute with Arial TTF | 18:41.01 |
| chrisl | FWIW, the code I've got here to do automagic CIDFont substitution in Ghostscript *seems* to render the file correctly using DroidSansFallback.ttf | 18:41.34 |
| ray_laptop | chrisl: is that what you told Raed to do? (sounds vaguely familiar) | 18:42.06 |
| chrisl | ray_laptop: no, I had to backtrack on it, because there's a TTF cmap table type I had to implement for DroidSansFallback which isn't committed yet | 18:43.00 |
| ray_laptop | I hope Miles gets on their case -- they clearly are a big support load. | 18:43.25 |
| Robin_Watts | There are ToUnicode entries | 18:43.27 |
| chrisl | Raed is probably using msminscho.ttc or something | 18:43.34 |
| ray_laptop | for Arial ? Why not just use arial.ttf | 18:44.10 |
| Robin_Watts | ray_laptop: Yes, they are throwing a lot of stuff our way at the moment, but frankly, I'd rather they hit it and had us fix it, rather than... the big customer that's looking at mupdf now. | 18:44.26 |
| | Except for this one, he's been finding real problems. | 18:44.56 |
| chrisl | ray_laptop: something like msmincho.ttc is better as a "catch-all" substitute | 18:45.00 |
| ray_laptop | Robin_Watts: I suppose so. But canaries can still be annoying | 18:45.04 |
| Robin_Watts | Indeed. | 18:45.12 |
| ray_laptop | chrisl: we have a "world trade" TTF that we can license them. Even better than msmincho | 18:45.43 |
| Robin_Watts | PS gurus.... how much would it hurt to have ghostscript start up in a state where it accepted binary postscript by default ? | 18:46.00 |
| ray_laptop | We bought it from URW and offered it to cust 130, but they ended up going with Andale-something-or-the-other.ttf | 18:46.41 |
| chrisl | ray_laptop: come the next release we'll be shipping DroidSansFallback so I don't know how eager they'd be | 18:46.51 |
| ray_laptop | so finding customers to pay Miles back for his investment would be nice | 18:47.13 |
| | How complete is DroidSansFallback (any idea how many glyphs) ? | 18:47.45 |
| | and how big | 18:47.57 |
| | I think the one we have has > 25k glyphs | 18:48.30 |
| | but I may not be remembering correctly | 18:48.51 |
| Robin_Watts | over 43000. | 18:49.10 |
| ray_laptop | I really should run my errand.... | 18:49.11 |
| chrisl | ray_laptop: the DroidSansFallback I've got is 3.5Mb#] | 18:49.33 |
| ray_laptop | hmm... the ones I recall were all much bigger. | 18:50.04 |
| chrisl | tor8: have you got a link to that page we were looking at with Droid font details on it? | 18:50.57 |
| ray_laptop | don't bother on my account. I was just curious. Sounds like Droid scores again ! | 18:51.34 |
| chrisl | ray_laptop: no, you just reminded me I meant to ask Tor anyway! | 18:51.55 |
| | Robin_Watts: why do you want to consume binary from startup? | 18:52.55 |
| Robin_Watts | http://www.ffonts.net/Droid-Sans-Fallback.font | 18:53.13 |
| | chrisl: Cos then I can use binary postscript in the mkromfs blob to save spage. | 18:53.33 |
| | space. | 18:53.36 |
| chrisl | How much space would it save? | 18:53.49 |
| Robin_Watts | 300K. | 18:53.57 |
| ray_laptop | Robin_Watts: is that mostly the CMaps or the other init files ? | 18:55.07 |
| ray_laptop | can't recall | 18:55.52 |
| Robin_Watts | me either. | 18:56.18 |
| chrisl | Finger in the air guess, I don't see why it would cause any problems, but you'll really need input from Alex | 18:56.42 |
| | Robin_Watts: BTW, that ffonts.net link is for an old version of the Droid font - I think the newer ones have even more glyphs | 18:57.27 |
| ray_laptop | because storing the cmaps the way mupdf does and generating them when requested from gsiorom (special detection) might be even better. | 18:57.28 |
| Robin_Watts | CMaps look to shrink by a noticable amount. | 18:57.33 |
| | ray_laptop: Indeed. | 18:57.44 |
| chrisl | ray_laptop: that's problematic for the Postscript world | 18:58.02 |
| ray_laptop | we can be as tricky as we want :-) (and have time to implement) | 18:58.07 |
| | chrisl: no, if we generate a valid PS file (on the fly) when asked for Resource/CMap/___ that should work | 18:58.49 |
| chrisl | But it's messy, IMHO...... | 18:59.22 |
| ray_laptop | i.e. "uncompile" tor's CMap data | 18:59.36 |
| | chrisl: I didn't say it wasn't messy -- just a way to reduce the rom footprint | 19:00.04 |
| Robin_Watts | The need for uncompiling CMaps comes from the fact that they are a specific postscript structure, right ? | 19:00.53 |
| | That won't be affected by it being binary in the file though? | 19:01.09 |
| chrisl | They're just dictionaries, as far as Postscript jobs are concerned | 19:01.20 |
| Robin_Watts | (i.e. it's the structure that matters, not the lexical flattening of that structure?) | 19:01.28 |
| | Right, that should be OK. | 19:01.32 |
| ray_laptop | we'd have to see how much space it would save over Robin_Watts' binary storage and then have a customer that cared (as cust 711 did) | 19:01.47 |
| chrisl | Yep, a binary PS stream that builds the same dictionaries would be absolutely fine | 19:01.57 |
| ray_laptop | chrisl: right. PS programs don't actually read the CMap data -- they just execute it to load a dict | 19:02.42 |
| | bbaib... | 19:03.05 |
| ray_laptop | keeps saying that :-) | 19:03.22 |
| chrisl | I have to head off to play a squash match that I *really* don't feel like playing - oh well...... 'night all! | 19:04.17 |
| Robin_Watts | tor8: ping ? | 19:07.21 |
| mvrhel_laptop | ray_laptop: or anyone else. any suggestions on how we want to turn off color management for source Device colors (e.g. DeviceRGB DeviceGray DeviceCMYK) as a command line option? | 19:07.25 |
| | I seem to have things working (or very close) | 19:07.39 |
| Robin_Watts | You're proposing having color management disabled for DeviceRGB etc, but enabled for CalRGB ? | 19:08.10 |
| mvrhel_laptop | yes | 19:08.16 |
| Robin_Watts | It seems to me that there are at least 3 possible states. | 19:08.37 |
| mvrhel_laptop | right now we effectively are really running in a -dUseCIEColor mode always | 19:08.38 |
| | in that every color is defined by an ICC profile | 19:08.51 |
| Robin_Watts | 1) Off for ALL spaces, 2) Off for Device spaces, on otherwise, 3) On for all spaces. | 19:09.00 |
| | Currently we're in 3, right ? | 19:09.11 |
| mvrhel_laptop | 1 is not an option | 19:09.14 |
| Robin_Watts | Why not ? | 19:09.20 |
| mvrhel_laptop | we have ICC profiles and CIELAB color spaces | 19:09.25 |
| | as source colors | 19:09.29 |
| | ignoring them like mupdf does is really not something we want to do | 19:09.47 |
| | ghostscript has never done that | 19:10.01 |
| Robin_Watts | Would 8.71 not have been doing 1) ? | 19:10.02 |
| mvrhel_laptop | no | 19:10.04 |
| Robin_Watts | Fair enough. | 19:10.12 |
| | So just 2 or 3 then. | 19:10.24 |
| mvrhel_laptop | yes. we use to make use of -dUseCIEColor to determine this | 19:10.45 |
| chrisl_away | mvrhel_laptop: traditionally, in Postscript terms, it would be a user parameter, as it's Ghostscript specific, but I don't know how that would sit with the other languages | 19:10.55 |
| Robin_Watts | Would 8.71 have handled CalRGB differently to DeviceRGB ? | 19:11.10 |
| mvrhel_laptop | yes | 19:11.14 |
| | it would have created a joint CIE cache for the CalRGB remap | 19:12.11 |
| | and done the dumb conversion for DeviceRGB | 19:12.24 |
| | the question I have, is how do we want the user to turn on dumb color management for source Device colors | 19:13.07 |
| Robin_Watts | mvrhel_laptop: Excuse the stupid questions here, but... | 19:14.44 |
| | We specify color profiles on the command line, right ? | 19:15.08 |
| mvrhel_laptop | yes | 19:15.46 |
| Robin_Watts | Suppose I specify a 'null' file for the RGB color profile. | 19:15.50 |
| mvrhel_laptop | not an option | 19:16.00 |
| Robin_Watts | Would that not be a good indicator that I wanted the dumb color management for RGB? | 19:16.15 |
| mvrhel_laptop | we have default ones that are used if one is not specified | 19:16.18 |
| | and we have ones for CMYK, RGB, gray | 19:16.44 |
| Robin_Watts | Right. if we do -sDeviceRGB=somefile.icc we use somefile.icc | 19:16.46 |
| | if we don't specify it at all, we get the defaults. | 19:16.55 |
| | If we specify "-sDeviceRGB=" then that would mean be dumb. | 19:17.18 |
| mvrhel_laptop | but what happens to CMYK, Gray? | 19:17.30 |
| Robin_Watts | (I've got the command line options wrong, I know, but...) | 19:17.31 |
| | They use the defaults. | 19:17.44 |
| mvrhel_laptop | yuck | 19:17.49 |
| Robin_Watts | Unless you also use -sDeviceGray= | 19:17.53 |
| mvrhel_laptop | I think it should be all DeviceXXXX use dumb or none use dumb | 19:18.11 |
| Robin_Watts | It means you can control what spaces you use CMM for. | 19:18.13 |
| mvrhel_laptop | I don't really see that being of interest to anyone | 19:18.27 |
| | and it makes me have to keep track of which "Device" source space is being managed | 19:19.29 |
| Robin_Watts | mvrhel_laptop: I thought you'd abstracted the CMM thing so that some links went to the dumb one, and some went to the real one? | 19:20.07 |
| mvrhel_laptop | yes. | 19:20.30 |
| | and this would occur for color spaces that were of the DeviceXXX type | 19:20.52 |
| | if it is enabled | 19:20.57 |
| | I could add in another set of flags that checks for each DeviceXXX type | 19:21.13 |
| | but I don't see anyone wanting that | 19:21.20 |
| Robin_Watts | So why do you need to keep track? Is it not just a matter of creating the appropriate link when you go to load the profile of each type ? | 19:21.32 |
| ray_laptop | mvrhel_laptop: since UseCIEColor is a device param (why Adobe did that remains a mystery), the other parsers will have an easier time with a device param (-dUseQuickColor or something) | 19:21.42 |
| mvrhel_laptop | ah. there we go | 19:21.56 |
| Robin_Watts | (when you go to load the icc profile for DeviceRGB, if the filename is empty, then create a dumb link, otherwise load from the filename (or default)) | 19:22.38 |
| mvrhel_laptop | Robin_Watts: the link is not really created at the time the profile is loaded | 19:22.56 |
| | the link is created later when we want to do a transformation | 19:23.11 |
| Robin_Watts | Right, ok. | 19:23.17 |
| | But suppose someone comes out with a new type of color profile. | 19:23.29 |
| | i.e. a non-ICC one. | 19:23.37 |
| mvrhel_laptop | hehe | 19:23.39 |
| | ok | 19:23.44 |
| Robin_Watts | and we want to add support for that. | 19:23.44 |
| mvrhel_laptop | yes | 19:23.50 |
| Robin_Watts | We'd detect the type when we load the profile, right? | 19:23.52 |
| ray_laptop | IMHO, we want the default behavior to be "good" color. | 19:23.53 |
| mvrhel_laptop | we will need a CMM to handle this profile type | 19:24.05 |
| Robin_Watts | and then fork into the appropriate CMM. | 19:24.10 |
| mvrhel_laptop | yes | 19:24.12 |
| | we would likely look at the magic number for the profile and send it off to the proper place | 19:24.31 |
| Robin_Watts | All I'm suggesting is that we recognise a specified empty filename as being the 'dumb' profile. | 19:24.54 |
| mvrhel_laptop | yes I understand | 19:25.04 |
| Robin_Watts | It seems fairly orthogonal to me. | 19:25.06 |
| Robin_Watts | likes avoiding special cases. | 19:25.18 |
| mvrhel_laptop | I do to | 19:25.25 |
| | to me having to do three specifications that the profile is NULL (which would be the common case) is more work than a single parameter | 19:26.06 |
| ray_laptop | Robin_Watts: I see -- so the default file name is NOT empty, someone would have to specifically set an empty name, right ? | 19:26.15 |
| Robin_Watts | yes. | 19:26.24 |
| mvrhel_laptop | but most people who want the quickcolor will not want to do three options on the command line to do this | 19:27.05 |
| Robin_Watts | phone, sorry. | 19:27.52 |
| ray_laptop | mvrhel_laptop: we can always provide a file that users can invoke with @lib/quickcolor | 19:28.04 |
| | that sets all three | 19:28.20 |
| mvrhel_laptop | I just have not seen anyone asking for this capability vs. I think there is interest in having the option for all DeviceXXX color to do the quick approach | 19:28.22 |
| | I really liked the simple case of the device parameter.... | 19:29.18 |
| ray_laptop | putting command line options into a file to be invoked with '@' removes the pain | 19:29.19 |
| mvrhel_laptop | this has problems though | 19:30.03 |
| ray_laptop | mvrhel_laptop: I'm fine either way, so feel free to do it whichever way you want -- just don't ask Robin_Watts for advice ever again ;-) | 19:30.10 |
| mvrhel_laptop | hehe | 19:30.15 |
| ray_laptop | the place I went to for a vacuum part didn't have it. Have to go further, so I'll be offline. | 19:30.44 |
| mvrhel_laptop | this approach makes things a bit more difficult for me in the managing of the profiles that are used as defaults for the source spaces and the output device | 19:30.45 |
| ray_laptop | bbiaw. Call me if you want | 19:30.55 |
| mvrhel_laptop | ok thanks for the input ray_laptop | 19:30.57 |
| | ok. need to grab some lunch. thanks for the suggestions Robin_Watts. I will think about this a bit more. | 19:37.05 |
| Robin_Watts | (still on phone, but for the logs...) I'd support a -dUseFastColor option as a shorthand for -sDEVICERGB= -sDEVICECMYK= etc | 19:51.59 |
| tor8 | Robin_Watts: pong. | 19:57.41 |
| Robin_Watts | tor8: sorry. | 20:03.06 |
| | I replied to the last message from Raed. | 20:03.14 |
| | I'm hitting the limits of my font knowledge. | 20:03.32 |
| | mvrhel: Just got off the phone. | 20:07.14 |
| mvrhel | just got home to eat some lunch... | 20:07.34 |
| Robin_Watts | I'd support a -dUseFastColor option as a shortcut for -dDEVICERGB= -dDEVICECMYK= etc | 20:08.04 |
| mvrhel | I think for the time being, I am going to just have the -dUseFastColor and if there is any interest in the option to be able to do one device color and not the others (which I don't belive will be the case) then I will do it the way that you suggest | 20:10.05 |
| Robin_Watts | mvrhel: Back in the mists of time, I had a similar problem to this. | 20:16.03 |
| | In that I had something that triggered on the types of a file. | 20:16.30 |
| | Never mind... | 20:17.02 |
| | mvrhel: Do it whichever way causes you least pain. | 20:17.14 |
| mvrhel | well I want to balance pain with need. And while I am all about having the solution be flexible, I don't want to overly complicate things if there is no real need to have it do certain features | 20:18.23 |
| | generally gs would either do CM for the DeviceXXX color spaces or not do it. That will be the situation we will be back in after I get this committed | 20:19.20 |
| Robin_Watts | tor8: Are you handling the invalid mask thing, or would you like me to ? | 21:18.43 |
| kens | Are you going to ignore the invalid entry ? | 21:19.40 |
| mvrhel | kens: is that question for me? | 21:21.11 |
| kens | Nope, tor8 and Robin_Watts | 21:21.21 |
| mvrhel | ok good | 21:21.25 |
| tor8 | Robin_Watts: I tried changing fz_to_int to round for floats | 21:21.38 |
| | I got some rather interesting results | 21:21.42 |
| kens | I htink it would be better to validate and discard if not valid | 21:22.03 |
| tor8 | pdfTeX files render at different image sizes (their mediaboxes have floating point values) | 21:22.41 |
| | and one file that looked like garbage before now looks correct! | 21:22.53 |
| | but I'm inclined to do both the rounding behavior and explicit check for validity in the mask | 21:24.14 |
| kens | Well if the rtouding helps for other purposes, that makes sense | 21:24.47 |
| tor8 | kens: it's pretty minor, the only real difference is how we end up treating fractional mediaboxes | 21:25.16 |
| kens | A progression is always nice ;-) | 21:25.46 |
| tor8 | Robin_Watts: 3 patches in http://ghostscript.com/~tor/stuff/ for you to rebase onto context :) | 21:31.34 |
| | and let's swap over to context tomorrow | 21:31.58 |
| kens | Night | 21:40.45 |
| Robin_Watts | tor8: The explicit check sounds correct to me. | 23:06.50 |
| | tor8: We need to do any API tweaking we need to before we swap over, right? | 23:07.18 |
| tor8 | Robin_Watts: hmm, there is that. | 23:08.04 |
| | anyway, let's agree to stop working on the 'master'. | 23:08.28 |
| | there are a few merge conflicts remaining in x11_main.c | 23:08.41 |
| sebras | tor8: ok, so there is a no-bugfix-period for sometime until context is done and merged..? | 23:12.33 |
| | ok, anyways... good night! | 23:26.48 |
| | Forward 1 day (to 2011/12/08)>>> | |
IRC Logs
