| | <<<Back 1 day (to 2011/11/22) | 2011/11/23 |
| Robin_Watts | tor8: ping ? | 00:37.38 |
| tor8 | Robin_Watts: pong. | 00:37.57 |
| Robin_Watts | Virtual straw drawing time... | 00:38.05 |
| | You want to talk to them or shall I ? | 00:38.14 |
| tor8 | looks like they want an app, not a library... | 00:38.30 |
| | you're better at defusing that sort of thing ;) | 00:38.50 |
| Robin_Watts | ok. | 00:39.21 |
| tor8 | I don't know what you think when you read the requirements list | 00:40.24 |
| | I mean, do they really expect a pdf rendering library to have timers and implement cross fades? | 00:41.27 |
| Robin_Watts | I'll send them a reply saying that mupdf can handle the reading of the file and the rendering of the pages to images on demand. | 00:42.46 |
| | They can then implement fades/timers etc as they see fit. | 00:43.07 |
| mvrhel | henrys: are you there? | 00:51.44 |
| | so I am sending another email to customer 190 about upgrading | 00:52.54 |
| | ok. henrys: email sent. I don't know what else I can to do to get them to upgrade short of going there and doing it myself | 01:15.58 |
| | I can't imagine it taking more than a few days for him to do this upgrade | 01:17.04 |
| | I have to think that there is something going on there | 01:17.16 |
| | dinner time here. I will be back in a bit | 01:17.32 |
| arthurf | tor8: Thanks for the fix and password support for the iOS MuPDF. I examined the feedback on the Adobe Reader to see what people wanted the most for enhancements. | 04:35.57 |
| | When I'm not quite as sleepy, I'll find the enhancement that was asked about the most - and will write another enhancement request. I suspect the answer is nested folders for PDFs. | 04:38.26 |
| henrys | I'm back mvrhel, my read is he doesn't want to support both products and he's letting the gs product gradually die - but I have cynical streak ;-( | 05:57.56 |
| | send me mail if you want to talk I'll be away from IRC. | 05:59.39 |
| Robin_Watts | Morning tor8. | 12:41.14 |
| tor8 | morning Robin_Watts | 12:52.46 |
| Robin_Watts | Is there a way of telling that an image is from inside a type3 font, I wonder... | 14:33.28 |
| kens | I think not | 14:33.40 |
| Robin_Watts | I've cut the grid fitting back so it only grid fits imagemasks that are 1 wide or 1 high. | 14:34.14 |
| kens | Why do you need to know, want tohandle them differently ? | 14:34.19 |
| Robin_Watts | and it looks pretty good. | 14:34.33 |
| | except for fonts where - suddenly becomes thicker. | 14:34.51 |
| chrisl | You could check the top of the dictionary stack - it should be the font dictionary, IIRC | 14:34.54 |
| Robin_Watts | or _ | 14:34.55 |
| | chrisl: This is from within the graphics lib. | 14:35.09 |
| chrisl | Ah, well no, you can't tell | 14:35.23 |
| Robin_Watts | I was hoping for penum->in_type3 or something. | 14:35.30 |
| | is that something that could be easily fixed? | 14:36.01 |
| | Type 3 font handling - is that all done at the PS level ? | 14:36.18 |
| chrisl | "Fixed"? It's not broken | 14:36.26 |
| Robin_Watts | chrisl: yeah, ok, fixed was a bad word. | 14:36.46 |
| | Is that information that could easily be made available, then. | 14:37.07 |
| chrisl | The problem is, the image(mask) operator has no idea it's being called from inside a font | 14:37.21 |
| kens | cache device might help | 14:37.54 |
| Robin_Watts | We could maybe have a graphics state entry for 'in type3', and then set that/unset that with a custom operator around type3 fonts ? | 14:38.23 |
| | kens: howso ? | 14:38.40 |
| kens | presence of cache device == font | 14:38.53 |
| | It gets pushed by font ops | 14:39.09 |
| | And you can only get images in type 3 | 14:39.27 |
| chrisl | Is that reliable - what if the cache is bypassed, or disabled? | 14:39.35 |
| kens | If teh image is too big for the cache, then its a silly font. But it could be disabled | 14:39.58 |
| | Twechnically. But its unlikely | 14:40.18 |
| chrisl | Does the "show_gstate" entry exist in the graphics state you have available? | 14:40.48 |
| Robin_Watts | I don't have one trapped in the debugger currently. | 14:41.14 |
| | but I can try... | 14:41.18 |
| kens | If so that owuld tell you it was text | 14:41.27 |
| chrisl | It's used in loads of places in the graphics library code, so that's probably a good bet | 14:41.49 |
| kens | Hevily used by pdfwrite too | 14:42.06 |
| Robin_Watts | Great. | 14:42.08 |
| chrisl | Yep, that should *always* be set for glyph rendering | 14:42.38 |
| AlecTaylor | Hmm, know where I can find the 1.4 standard? | 15:01.16 |
| kens | The Adobe web site ? | 15:01.33 |
| AlecTaylor | Yeah, looking around... | 15:01.45 |
| Robin_Watts | The 1.7 standard is the one that tends to get passed around these days. | 15:01.47 |
| | Would 1.7 do? | 15:01.55 |
| kens | I have a copy of the 1.4 reference | 15:01.59 |
| AlecTaylor | kens: Can you send me a copy? xdcc or other method :) | 15:02.27 |
| AlecTaylor | is just making some sweeping comments about logical structure in PDFs based on standards, so needs to ensure he's getting his facts right | 15:03.03 |
| | Robin_Watts: You hacked IRC! - Lower-case and uppercase! | 15:03.36 |
| kens | AlecTaylor : need a mail address | 15:03.44 |
| AlecTaylor | alectaylor6@gmail.com | 15:03.50 |
| kens | Will go to find it | 15:04.06 |
| AlecTaylor | Thanks :) | 15:04.19 |
| Robin_Watts | ? | 15:04.27 |
| AlecTaylor | If you have multiple different standard PDFs, send me them all :) | 15:04.31 |
| | Robin_Watts: My chan user list has robin_watts and Robin_Watts | 15:04.50 |
| Robin_Watts | The 1.7 standard contains everything that the 1.4 does, plus additions. | 15:05.14 |
| | Simultaneous tea, and no tea. | 15:05.27 |
| | I think you'll find that one is "robin_watts_mac". | 15:05.44 |
| AlecTaylor | Robin_Watts: Yeah, but I want to know precisely what additions were made in each version, right down to the wording | 15:05.56 |
| kens | AlecTaylor : 15 MB PDF on the way | 15:07.38 |
| AlecTaylor | Thanks | 15:08.04 |
| | Hmm | 15:08.06 |
| | Does GMail support that? | 15:08.12 |
| Robin_Watts | Damn. I don't have a pgs in general, only a pis. | 15:08.15 |
| kens | I have all the versions, but they are too big in total to send | 15:08.17 |
| AlecTaylor | LZMA2? | 15:08.30 |
| | But nw, I'll await receipt | 15:08.45 |
| kens | PDF is fairtly incompressible | 15:09.04 |
| AlecTaylor | mmm | 15:09.09 |
| | Maybe http://mediafire.com or something like that? | 15:09.19 |
| AlecTaylor | tries compressing his PDF | 15:09.29 |
| kens | can't be arsed with funny compression methods | 15:09.39 |
| Robin_Watts | http://lmgtfy.com/?q=pdf+reference+1.7 | 15:10.13 |
| AlecTaylor | Got a 145MB PDF down to 123MB | 15:10.56 |
| | Hmm, yeah, that's not that great | 15:11.03 |
| | But yeah, you should be able to upload large PDFs to mediafire for free without trouble | 15:11.38 |
| AlecTaylor | doesn't think his GMail will allow him to receive 15MB | 15:12.01 |
| kens | Mine is OK with files that big | 15:12.18 |
| AlecTaylor | kens: What's its size limit anyway/ | 15:12.30 |
| kens | No idea | 15:12.36 |
| AlecTaylor | mmm | 15:12.40 |
| | Has it sent on your end yet? | 15:12.53 |
| | Wahhh, finally found it | 15:15.44 |
| AlecTaylor | is at: http://www.adobe.com/devnet/pdf/pdf_reference_archive.html | 15:15.48 |
| kens | not gone yet | 15:16.44 |
| | Finished sending | 15:17.19 |
| AlecTaylor | is reading page 76 | 15:19.20 |
| AlecTaylor | is reading page 485 | 15:21.03 |
| ray_laptop | morning, all | 15:21.15 |
| | I saw a discussion about whether or not painting was for text... | 15:21.45 |
| kens | specifically images | 15:22.17 |
| Robin_Watts | ray_laptop: Yeah. | 15:22.28 |
| ray_laptop | recall that we now have graphics_object_type | 15:22.31 |
| kens | But we need to know if it was from a font | 15:22.42 |
| ray_laptop | that color management uses (and devices that want to encode it in the color) | 15:23.12 |
| Robin_Watts | ray_laptop: That might be a neat answer, yes. | 15:23.39 |
| | if an image is plotted as part of a type 3 font, the graphics_image_type should still be text, right ? | 15:24.19 |
| ray_laptop | oops. I meant 'graphics_type_tag | 15:24.30 |
| chrisl | Doesn't that only get set if the device supports it? | 15:24.51 |
| ray_laptop | chrisl: no, I changed that so it is always set -- there is a special flag bit if the device uses it in it's color encoding: GS_DEVICE_ENCODES_TAGS | 15:27.15 |
| chrisl | ray_laptop: oh, cool. | 15:27.41 |
| Robin_Watts | ray_laptop: So for every single device I can look at dev->graphics_type_tag ? | 15:27.46 |
| ray_laptop | the color management can use it for all devices since there can be separate profiles depending on graphics_type | 15:28.05 |
| Robin_Watts | Are we sure that that doesn't go wrong for Type3 fonts containing bitmaps ? | 15:28.13 |
| ray_laptop | Robin_Watts: yes, it's part of the standard 'gx_device' struct | 15:28.32 |
| Robin_Watts | i.e. if I get a bitmap plotted as part of a Type 3 glyph, that should be tagged as text, not images. | 15:28.43 |
| ray_laptop | Robin_Watts: not sure, but we can fix it if it is wrong -- it is supposed to allow for combined tags: GS_TEXT_TAG | GS_IMAGE_TAG | 15:29.33 |
| Robin_Watts | gxicolor, gximono,gxiscale all set it to GS_IMAGE_TAG regardless of where the images come from. | 15:29.37 |
| | ray_laptop: I would argue that we don't want a combined tag in those cases. | 15:29.55 |
| ray_laptop | Type 3 text that draws a bitmap ? | 15:30.16 |
| Robin_Watts | PDF Type 3 fonts have every glyph as a stream of pdf operators. | 15:30.47 |
| | those streams can (and frequently do) send bitmaps. | 15:31.05 |
| | (I'm sure you know this) | 15:31.15 |
| | As such, every pixel they send should be considered 'text' I reckon, not 'image'. | 15:31.45 |
| ray_laptop | Robin_Watts: right, but do we want to maintain the 'or' of both types ? | 15:31.59 |
| Robin_Watts | ray_laptop: Keeping the or would seem wrong to me. | 15:32.26 |
| ray_laptop | currently only the pdf14 device creates combined tags, and that is only when the device encodes tags | 15:32.37 |
| | so when a device that encodes tags will get pixels with a combo tag and can decide on the precedence | 15:33.16 |
| | so if a pixel is a blend of image and text, for example, the device can decide how it wants to encode it | 15:33.48 |
| Robin_Watts | Right. but without pdf14 (i.e. without transparency), it seems wrong that pixels that result from a text output operation should ever be flagged as being from images. | 15:34.16 |
| | just because they happen to use a different font encoding scheme. | 15:34.29 |
| ray_laptop | but currently, we don't keep the text bit set when doing the painting for Type3 glyphs. | 15:34.51 |
| Robin_Watts | Right. That's what I'm saying is wrong. | 15:35.31 |
| ray_laptop | but if we want to, we can have it so it has both bits set | 15:35.38 |
| Robin_Watts | and that would be wrong too, IMHO. | 15:35.57 |
| chrisl | If we did that, we'd need *another* method of identifying the result of a blend operation | 15:36.07 |
| Robin_Watts | I understand that the scheme is capable of that. I just don't think it's desirable in this case. | 15:36.24 |
| ray_laptop | and let the clients that use the tag (e.g. cms) decide how to handle it | 15:36.26 |
| chrisl | I would argue that Type 3 font bitmap != text blended with another object | 15:37.29 |
| ray_laptop | the cms would probably give precedence to the 'text' type (so that bitmaps use the text color profile) | 15:37.31 |
| Robin_Watts | If pixels are set as a result of a text operation they should get a pure text tag. | 15:37.50 |
| | If pixels are set as a result of an image operation they should get a pure image tag. | 15:38.04 |
| | UNLESS transparency is used, when a blended tag is acceptable. | 15:38.14 |
| ray_laptop | currently they will get a tag depending on the painting op (image or path) | 15:38.26 |
| Robin_Watts | I'm agreeing with chrisl's last statement in a more long winded way :) | 15:38.34 |
| | ray_laptop: Right. And I'm saying that's wrong. | 15:38.40 |
| ray_laptop | Robin_Watts: I agree that is wrong, but I don't (necessarily) agree that a combo tag is inappropriate | 15:39.09 |
| | maintaining a combo tag lets the client decide how to handle it. | 15:39.29 |
| Robin_Watts | ray_laptop: Suppose I have it set up so that 'text' tagged stuff gets plotted using real black. | 15:39.39 |
| ray_laptop | as I said above, for color_profile choice, the 'text' would take precedence | 15:39.57 |
| Robin_Watts | and 'image' tagged stuff gets plotted using cmy. | 15:39.58 |
| | and 'blended' stuff uses something midway between the two. | 15:40.14 |
| ray_laptop | Robin_Watts: that's what would happen now | 15:40.15 |
| | and I think the cms would probably want to give precedence to the 'text' but | 15:40.42 |
| Robin_Watts | At the moment, any use of a Type3 font with bitmaps in would produce 'muddy' text. | 15:40.42 |
| ray_laptop | s/but/bit/ | 15:40.47 |
| Robin_Watts | If we use a blended tag, we'd get 'less muddy' text, but still not right. | 15:41.17 |
| | I reckon we should only ever get blended tags when we have transparency involved. | 15:41.39 |
| ray_laptop | we can discuss chrisl's point that transparency blended text+image is not necessarily the same as image in Type3 glyph text+image | 15:42.02 |
| Robin_Watts | That's the absolute key point, yes. | 15:42.23 |
| chrisl | To my mind, a glyph is a glyph, regardless of how it's painted, so should be marked as text. | 15:42.52 |
| Robin_Watts | agreed. | 15:43.00 |
| ray_laptop | Robin_Watts: IMHO, the key point is that now bitmaps in Type3 glyphs are 'image' type | 15:43.14 |
| | which is wrong | 15:43.22 |
| chrisl | also agreed | 15:43.31 |
| Robin_Watts | ray_laptop: I think we're all agreed that's wrong :) | 15:43.35 |
| | What is at question is how to fix it. | 15:43.44 |
| | Chrisl and I are arguing that fixing it by sending a blended tag would be wrong. | 15:44.21 |
| | You seem to be (and please forgive me if I've got this wrong) arguing that sending a blended tag would be an acceptable solution. | 15:44.53 |
| chrisl | I thought the object tags were implemented as they were *specifically* to allow identification of areas resulting from transparency blend operations (as well as other uses)? | 15:46.23 |
| ray_laptop | currently only the transparency stuff sets a blended tag, and I am OK with that, but I would like mvrhel to weigh in | 15:49.55 |
| | and even if we set a combo tag, the cms can decide that it wants to ignore other bits when the 'text' bit is set | 15:50.49 |
| | I don't know what it does now | 15:51.22 |
| chrisl | The problem I'd see is that, from the tag value, the cms couldn't decide to ignore other bits for Type 3 glyphs, and use them for the result of trans blending - which I thought was important. | 15:52.43 |
| | But yes, we should see what mvrhel has to say about it...................... | 15:53.25 |
| ray_laptop | oh, that's right -- unless the device implements a 'put_image' the default put_image will end up painting an image (for the whole page), so (I'm pretty sure) it will use the 'image' profile | 15:53.26 |
| Robin_Watts | Clearly soliciting mvrhels opinion is the right thing to do. | 15:53.55 |
| ray_laptop | chrisl: we could add a bit for 'transparency_blend' | 15:54.09 |
| | so the client _could_ tell them apart | 15:54.34 |
| Robin_Watts | If it was held to be important that we should distinguish between 'text' and 'text that uses images as part of the glyphs' and 'blended text and images', we could use another bit. | 15:54.41 |
| | ray_laptop: You typed faster than me :) | 15:54.51 |
| ray_laptop | and I agree that I'd like mvrhel's input | 15:55.00 |
| chrisl | I can see where knowing image data from a Type 3 glyph might be useful, but I think that's a separate requirement from being able to determine it's the result of blending text with other object(s) in transparency. | 15:56.21 |
| ray_laptop | chrisl: sounds like you and I are mostly in agreement. | 15:56.49 |
| | by maintaining the 'combo' for Type3, we let the client that uses the tag make the decision based on the most information. | 15:57.30 |
| Robin_Watts | as long as we maintain a separate bit for transparency blends, yes, I think I agree. | 15:58.04 |
| ray_laptop | but I agree that the CMS should probably use the 'text' profile | 15:58.13 |
| Robin_Watts | That would give the user the maximum possible information. | 15:58.15 |
| chrisl | Yep, the point is, we must provide a way to differentiate between a bitmap glyph, and glyph blended with an image in transparency | 15:59.39 |
| ray_laptop | chrisl: but I don't think we need to differentiate between normal text transparency blended with an image and a Type3 painted with a bitmap trans blended with an image | 16:01.20 |
| | both cases would have 'transparency + text + image' set | 16:01.56 |
| chrisl | No, I agree - that would be overkill! | 16:02.14 |
| ray_laptop | goes down a rabbit hole :-) | 16:02.21 |
| chrisl | I'm just waiting on mvrhel showing up with a completely different opinion ;-) | 16:03.20 |
| Robin_Watts | An alternative might be to have a new 'image' bit, 'image_as_part_of_text' or 'bitmap_glyph' or something. | 16:04.59 |
| | So we'd have 'text' for normal text, 'bitmap_glyph' for images as part of Type 3's, 'image' for images. | 16:05.59 |
| ray_laptop | I strongly object to the more simple method of just not changing the type if text is set (either way the text painting has to make sure and turn it off when done) | 16:05.59 |
| Robin_Watts | And then any combination would be as a result of a blend. | 16:06.30 |
| ray_laptop | oops. I _don't_ strongly object. Sorry | 16:06.34 |
| | and either way, the places where we set image or path will need to take the text bit into account. | 16:07.43 |
| Robin_Watts | That *would* differentiate between normal text transparency blended with an image and a Type3 painted with a bitmap trans blended with an image. | 16:08.07 |
| | yes. | 16:08.10 |
| ray_laptop | preserving it, and (depending on what we decide) not changing it or or-ing in their bit | 16:08.32 |
| chrisl | <sigh> let's try that clusterpush with the *right* code this time..... :-( | 16:11.25 |
| | and now that's queued, I need to run a couple of arrands - bbiaw | 16:15.16 |
| ray_laptop | What do you all think of having the vector devices (ps, px, svg, pdf, ps2) close and re-open if the OutputFile has a %d format ? | 16:18.41 |
| kens | THat sounds good to me. | 16:19.01 |
| | Would allow one file per page and so on | 16:19.09 |
| Robin_Watts | ray_laptop: Sounds smart to me | 16:19.22 |
| kens | Whihch is somethign that does gget asked for | 16:19.28 |
| ray_laptop | that would remove the issue that those devices don't respect the %d OutputFile one page per file | 16:19.33 |
| Robin_Watts | You were saying yesterday that *some* command line flags only get acted on before the first file. | 16:20.00 |
| | Is that the case for 'some' or 'all' (wasn't clear to me) | 16:20.23 |
| kens | Some I believe | 16:20.39 |
| ray_laptop | Robin_Watts: right. Some are used to initialize things and so don't get checked later | 16:20.48 |
| | all the argument processor does it to set a value in the systemdict | 16:21.08 |
| Robin_Watts | So, for clarity, I'll restate that in the way that I now understand it, and you can correct me if I'm wrong. All parameters are read and acted on in order, but some of them merely set values in the systemdict. Updating the systemdict values may not actually cause anything to change as the systemdict may only be read just before the first file is processed. | 16:22.49 |
| ray_laptop | it's gs_init.ps that collects the parameters for the current device, and if any are defined in systemdict, sets the value for those parameters (e.g. OutputFile) | 16:22.55 |
| | Robin_Watts: -d and -s just set values in systemdict | 16:23.45 |
| Robin_Watts | ray_laptop: Yeah. | 16:23.53 |
| ray_laptop | it's the initialization PS code that makes it look like one is setting device parameters. | 16:24.36 |
| Robin_Watts | Would it be feasible to detect changes to the systemdict (i.e. if we hit a -d or a -s between files), and somehow make the initialisation PS code run again? | 16:24.51 |
| ray_laptop | which is why it's hard for us to determine if someone gives a parameter that a device doesn't recognize, e.g. -dband_height=256 | 16:25.19 |
| ray_laptop | barfs | 16:25.37 |
| | Robin_Watts: but, yes, ANYTHING is possible | 16:26.09 |
| | actually, it would make it act more like the pcl, xps and ls command line processing -- they assume that -d and -s _ARE_ device parameters and do 'put_params' with them | 16:27.14 |
| Robin_Watts | ray_laptop: Why is that barfworthy? (I'm not saying it's not, just that my tastes are not yet so refined that I am offended by that :) ) | 16:27.22 |
| | -d defines something to be a number, -s defines something to be a string... do we have a -x to remove something from the systemdict? | 16:28.39 |
| ray_laptop | Robin_Watts: doing device parameters after running a job is one thing. Re-doing something like '-dDOINTERPOLATE -dNOINTERPOLATE' is messier | 16:29.22 |
| Robin_Watts | That's why I was wanting: gs -dDOINTERPOLATE file1.ps -xDOINTERPOLATE file2.ps :) | 16:29.58 |
| ray_laptop | other things, such as -dFirstPage= -dLastPage= and -dPDFDEBUG work now | 16:30.07 |
| | Robin_Watts: why -x ? Why not -dDOINTERPOLATE=false ??? | 16:31.08 |
| Robin_Watts | ray_laptop: That leaves a DOINTERPOLATE entry in the systemdict. | 16:31.40 |
| ray_laptop | recall that -dDOINTERPOLATE is the same as -dDOINTERPOLATE=true | 16:31.42 |
| | if it's there and false, that's OK | 16:32.03 |
| Robin_Watts | Right. Consider the equivalent in c preprocessors. #define X 1, #define X 0 and #undef X are all different. | 16:32.25 |
| ray_laptop | allowing for the -x (undef) of the parameters is messy too. | 16:33.33 |
| | but it has the advantage of making the addition of new parameters harder, so we won't proliferate options so much ;-) | 16:34.12 |
| Robin_Watts | ray_laptop: Why is -x hard? | 16:34.37 |
| | Is it not just a dictionary delete ? | 16:34.44 |
| ray_laptop | doing the dictionary undef is easy -- having an associated undef procedure for each parameter is harder. | 16:35.35 |
| | and IMHO we don't want to re-init between running jobs just because someone wants to change something like -sOutputFile or -dTextAlphaBits | 16:36.40 |
| Robin_Watts | I was assuming that if we reran the init code between each file, they'd reset to the defaults if they weren't there? But I guess this isn't important if everything treats false appropriately. | 16:37.16 |
| | -sOutputFile was exactly one of the cases I was thinking of :) | 16:37.28 |
| | For pdfwrite I'd like -sOutputFile to trigger the close/reopen of the device. | 16:38.16 |
| ray_laptop | allowing device parameter changes between jobs is not to bad (not barfworthy) since that makes it more like plmain | 16:38.20 |
| Robin_Watts | but I'm in unfamiliar territory here, so I'll bow to your/kens experience on this. | 16:38.46 |
| ray_laptop | Robin_Watts: OutputFile is a device parameter, so as long as we send the intermediate device parameters to the device, each can decide how to handle it. pdfwrite/ps2write 'put_params' can detect an OutputFile change and close and re-open | 16:39.57 |
| | and other 'vector' class devices (pxl, pswrite, svg, ..) | 16:40.29 |
| Robin_Watts | Hi mvrhel | 16:43.04 |
| ray_laptop | mvrhel: your ears were probably burning earlier -- we were discussing type tag bits | 16:43.05 |
| mvrhel | good morning | 16:43.23 |
| ray_laptop | specifically, how should we handle Type3 glyphs that paint with images and/or paths | 16:43.44 |
| mvrhel | oh that is a good question. | 16:44.02 |
| ray_laptop | mvrhel: do you just want to look at the logs ??? | 16:44.06 |
| mvrhel | yes. I am doing that now | 16:44.11 |
| ray_laptop | shuts up and lets mvrhel read :-) | 16:44.30 |
| henrys | minor correction here pcl and xl do not assume everything is a device param. For example FirstPage is not set as a devcie parameter. | 16:50.24 |
| ray_laptop | Robin_Watts: BTW, currently pdfwrite only processes the -sOutputFile device parameter during pdf_open -- its put_params ignores the setting AFAICT | 16:50.57 |
| mvrhel | interesting. so am I understanding that we are talking about gylphs that are filled with images? For color management, I would think one would want the object to be tagged as an image. At least that is what I would expect if I was a designer | 16:51.43 |
| Robin_Watts | ray_laptop: It would be hard (AIUI) for it to close/reopen during a put_params, so that's probably for the best :) | 16:51.59 |
| ray_laptop | mvrhel: I don't think any of us agree with that | 16:52.10 |
| mvrhel | I see | 16:52.17 |
| Robin_Watts | mvrhel: PDF has 'Type 3' fonts. | 16:52.26 |
| ray_laptop | we all think that Type3 text should use the text profile | 16:52.32 |
| | (which it doesn't do currently) | 16:52.49 |
| Robin_Watts | These are fonts where the glyphs are defined by a stream of PDF operators. | 16:52.55 |
| mvrhel | ah. not necessarily an image | 16:53.13 |
| kens | Robin_Watts : the same is true of PostScript, it also has type 3 fonts | 16:53.15 |
| Robin_Watts | This means they can involve lines. curves etc, but more often are a bitmap image. | 16:53.22 |
| ray_laptop | mvrhel: right -- can be any mix of painting operations | 16:53.31 |
| Robin_Watts | kens: I stand corrected. My PDF background is showing :) | 16:53.40 |
| ray_laptop | even shading and patterns | 16:53.43 |
| mvrhel | yes | 16:53.46 |
| | ok | 16:53.48 |
| kens | PostScritp type 3 fonts can be even more complex, since htey can involve programming | 16:54.18 |
| | But the poitn is that the (marking) operations are what counts | 16:54.33 |
| ray_laptop | so one idea is to have the 'text' bit inhibit changing it to anything else until we finish the text operation | 16:54.38 |
| | the other concept was to 'or' the text bit with the other painting bit | 16:54.58 |
| Robin_Watts | and yet another concept is to have a new set of bits for this case. | 16:55.20 |
| ray_laptop | by or-ing, we let the client that uses the type_tag decide how to handle it | 16:55.30 |
| Robin_Watts | oring has the disadvantage that we can't tell the difference between a type3 glyph that paints with an image, and some text and a image transparency blended together. | 16:56.23 |
| ray_laptop | but chrisl pointed out that pixels that are a transparent blend of image and text should be different to pixels that are Type3 glyph painted with an image | 16:56.35 |
| | what Robin_Watts said | 16:56.45 |
| Robin_Watts | ray has suggested that can be fixed by introducing a new 'blended' bit. | 16:56.59 |
| ray_laptop | so we just add (yet another) tag bit for 'transparently blended' | 16:57.15 |
| | there's an echo in here ;-) | 16:57.31 |
| Robin_Watts | That still leaves a few cases that can't be distinguished (but they are vanishingly small I suspect) | 16:58.27 |
| ray_laptop | when pdf14 blends the tag bits so that more than one is set, it would also set the 'transparently blended' bit | 16:58.30 |
| kens | I have to go, goodnight everyone | 16:58.40 |
| ray_laptop | bye, kens | 16:58.47 |
| mvrhel | how is the type3 font drawn? If I have a fill of one glyph with and image and one with a solid color when does the color management occur? Is the fill done through a bit mask or a clip path or something else? | 16:58.54 |
| | s/and/an/ | 16:59.17 |
| Robin_Watts | That sounds like a question for ken or chris, I fear. | 17:00.00 |
| | type3 glyphs can be of 2 different types. | 17:00.19 |
| | They can be colored or uncolored. | 17:00.27 |
| chrisl | colored are very rare, IME | 17:00.52 |
| Robin_Watts | for colored ones, they render to a bitmap that's cached, for uncolored to a grayscale mask, AIUI. | 17:01.11 |
| | chrisl: Indeed. I've never seen them outside a QL test, I think. | 17:01.40 |
| mvrhel | ok. what color space is the bitmap for the colored ones? | 17:01.42 |
| | is it in the device space? | 17:01.56 |
| chrisl | Any colorspace you can use in PS/PDF | 17:02.01 |
| mvrhel | oh. so it has its own color space | 17:02.13 |
| Robin_Watts | Urm... I thought it was device space. | 17:02.21 |
| mvrhel | I better read the documentation | 17:02.23 |
| | if its the device space then I am going to feel better | 17:02.35 |
| henrys | can I ask the related bug here? | 17:02.53 |
| Robin_Watts | henrys: This spun out of 692666 | 17:03.07 |
| ray_laptop | actually one of the early GS consultants had a whole line of colored fonts -- Soft Horizons (John DeRosiers) | 17:03.08 |
| chrisl | Well, the glyph *definition* can be in any color space, what we render into is another matter | 17:03.27 |
| Robin_Watts | henrys: though it won't immediately be obvious how :) | 17:03.34 |
| | chrisl: Right. | 17:03.43 |
| mvrhel | hehe. ok what to *we* render itno | 17:03.43 |
| | into | 17:03.46 |
| | s/to/do/ | 17:03.52 |
| | good grief cant tpye | 17:03.59 |
| chrisl | I'd *expect* that to be device space, but wouldn't swear to it | 17:04.08 |
| ray_laptop | chuckles | 17:04.11 |
| Robin_Watts | Currently we have tag bits for: 'text', 'image', 'path', right? | 17:04.44 |
| mvrhel | if its the device space, then that is nice since the proper color management will have occurred in the creation of the bitmap | 17:04.56 |
| ray_laptop | a colored Type3 font can set any colorspace, but it is expected to be cached in device color space (i.e. converted as painting is happening) | 17:05.21 |
| chrisl | mvrhel: by far the most common case is an imagemask, or 1 bit image - out there in the "real world"...... | 17:05.53 |
| Robin_Watts | we could add new tag bits for 'type3_image', 'type3_path' (or some better names) | 17:06.21 |
| | That way we'd keep the fact that 'combination tags can only come from blending', and there would be no cases that could not be distinguished. | 17:07.10 |
| ray_laptop | chrisl: for that case there isn't a problem, right ? the glyph will be writing to a 1-bit cachedevice and then will be painted as 'text' type, right ? | 17:07.15 |
| Robin_Watts | ray_laptop: The cache device stores the result as an image, and plays it out by calling image painting code. | 17:08.02 |
| | and that image painting code currently sets the tag type to image (I believe). | 17:08.17 |
| chrisl | ray_laptop: I'm not sure what happens if the cache is full - I can't remember if we just render the image(mask) directly to the output, then | 17:08.17 |
| ray_laptop | Robin_Watts: I see -- I thought it used 'copy_mono' | 17:08.37 |
| Robin_Watts | ray_laptop: I may be wrong actually. | 17:09.10 |
| chrisl | It should have the text bit set, otherwise we'd almost never see the text bit being set | 17:09.52 |
| Robin_Watts | I know that I'm seeing my image-only changes making a difference to stuff that is (prsumably) cached, but that's probably at creation time. | 17:09.54 |
| ray_laptop | Robin_Watts: probably so. | 17:10.14 |
| Robin_Watts | OK. Ignore what I said about the cache device playing it out as an image, sorry. | 17:10.18 |
| ray_laptop | so for what you need, Robin_Watts, either method that has the 'text' bit set (with or without the 'image' bit) will work | 17:11.06 |
| chrisl | As I said, the wrinkle there might be when the glyphs are uncached | 17:11.27 |
| Robin_Watts | ray_laptop: Yes, I could certainly live with that. | 17:11.45 |
| chrisl | ray_laptop: for what Robin needs now, does the show_gstate check not suffice? | 17:12.20 |
| ray_laptop | chrisl: the wrinkle is for colored Type3 AFAICT -- | 17:12.22 |
| Robin_Watts | chrisl: The problem is I need a pgs to get show_gstate. | 17:12.39 |
| | and I only have a pis. | 17:12.43 |
| chrisl | But that should be a gstate | 17:13.01 |
| Robin_Watts | in some cases it is, in some cases it isn't. | 17:13.14 |
| chrisl | Oh, that's odd - from which language? | 17:13.44 |
| Robin_Watts | If I get an image of some specific type (3 maybe? I forget immediately) that forks into 2 images within the code. | 17:13.46 |
| ray_laptop | Robin_Watts: there is a 'is_gstate' to tell you if it is an imager state only, or a gstate | 17:13.48 |
| Robin_Watts | ray_laptop: Indeed. | 17:13.57 |
| | One of those images gets a NULL pis, one gets the proper pgs. | 17:14.14 |
| | I run the risk of correcting one and not the other in that case. | 17:14.26 |
| | and that's bad (M'kay) | 17:14.34 |
| chrisl | Hmm, I'm not very familiar with that area of the code, but that doesn't sound right. | 17:15.06 |
| ray_laptop | Robin_Watts: you need a pgs to get the device (and thus the graphics_type_tag) as well | 17:15.50 |
| Robin_Watts | henrys: How we get here from 692666: gridfitting produces unfortunate effects in some cases. So I've currently whittled it down so I only gridfit orthogonal imagemasks that are either 1 pixel high or 1 pixel wide. | 17:15.54 |
| | And that's pretty good - but it has the side effect of thickening certain type3 glyphs - like '-' or '_' - in certain sans-serif fonts. | 17:16.35 |
| ray_laptop | Robin_Watts: that smells hackish | 17:16.36 |
| henrys | There is precedent in the code to identify fonts by setting fill_adjust to -1 - this tells the graphics library to dropout prevention for type42 fonts. | 17:16.36 |
| ray_laptop | fill_adjust is in the imager_state as well | 17:17.08 |
| Robin_Watts | So I'd like to NOT gridfit if I'm in a type3 glyph. hence the question of how do I detect I'm in a type3 - ray suggested using the tag, which lead to this discussion and the spotting of tags being potentially wrong. | 17:18.01 |
| | ray_laptop: This *is* a hack. | 17:18.15 |
| chrisl | ray_laptop: I'm thinking we *might* run into problems with any glyph that's rendered uncached, because the marking operations (I *think*) get passed straight to the "output" device (i.e. don't go through the cache device). | 17:18.38 |
| ray_laptop | Robin_Watts: is it always there, or is it conditional | 17:19.02 |
| Robin_Watts | chrisl: Right, but why would that affect the tag bits? The tag bits wouldn't be being set by the cache device, right? rather by the calling code. | 17:19.38 |
| henrys | Right so I was suggesting setting fill_adjust to -3 or something when a type3 is created that should get percolated into your image. Right? | 17:19.46 |
| Robin_Watts | ray_laptop: currently it's uncommitted. | 17:19.52 |
| | henrys: That might be a solution, yes. But it doesn't solve the wider 'tags are wrong with type3 glyphs that use bitmaps' problem. | 17:20.21 |
| chrisl | Robin_Watts: I'm not sure - I thought you said you were seeing the image tag being set of Type 3 glyphs | 17:20.30 |
| ray_laptop | chrisl: yes, but if we have the 'text' bit set, the color conversion can treat it as text so that uncached chars will use the text profile the same as ones from the cache | 17:20.54 |
| chrisl | ray_laptop: yes, the question in my mind is *where* the tag bit is being set. | 17:21.46 |
| Robin_Watts | chrisl: I said, that I can see in the code that plotting images unconditionally sets the tag bits to be IMAGE. | 17:21.51 |
| | It's the image code. | 17:21.55 |
| | so it will happen either when drawing directly onto the display or when drawing into the cache. | 17:22.12 |
| ray_laptop | right now the text tag bit gets erased by an image painted in a type3 glyph | 17:22.33 |
| | or for a stroke or fill setting the 'path' tag bit, for that matter. | 17:23.02 |
| henrys | I would be surprised if adobe treated type 3 fonts with images as fonts in all cases. Do we really have evidence of that. If that were so - two images one in a font and the other solo would have a discernable pixel shift. Interesting experiment. | 17:23.07 |
| chrisl | robin_watts: but when we image the glyph from the cache, the text bit should be set | 17:23.13 |
| ray_laptop | If we are painting a mask for an uncolored glyph, then no problem -- the text tag will be set when we paint the char from the cache | 17:23.49 |
| mvrhel | that all sounds good to me | 17:24.00 |
| Robin_Watts | OK. | 17:24.01 |
| chrisl | ray_laptop: not if the glyph is uncached | 17:24.10 |
| ray_laptop | but Robin_Watts needs the text bit to be there so he knows how to handle (not mess with) the imagemasks in a Type3 font (even when going to the cache) | 17:24.57 |
| Robin_Watts | so the problem reduces to only being a problem if a) it's uncached glyph ,or b) we want to be able to distinguish images in glyphs from normal text. | 17:25.31 |
| | b) may not be a problem. a) probably is. | 17:25.38 |
| ray_laptop | and chrisl points out that the uncached painting of a Type3 glyph ALSO needs to use the 'text' bit to get the same profile as a cached glyph | 17:25.43 |
| Robin_Watts | ray_laptop: No, I can possibly get away with henrys suggestion. (i.e. I don't necessarily need the tag fixed just for me) | 17:26.10 |
| ray_laptop | Robin_Watts: the show_gstate or the fill_adjust ? | 17:26.37 |
| chrisl | ray_laptop: I'm concerned that the tags will be wrong if we render *any* glyph uncached (not just type 3 ones) | 17:26.46 |
| Robin_Watts | fill_adjust. | 17:26.56 |
| ray_laptop | doesn't see an advantage to one vs. the other, or the tag bit | 17:27.43 |
| | all require a gstate, right ? | 17:27.55 |
| | and in some cases you have a NULL pis | 17:28.13 |
| henrys | no the adjust is in the image. | 17:28.18 |
| Robin_Watts | The NULL pis may be a problem :( | 17:28.40 |
| | but it's a smaller problem than me not having a pgs at all. | 17:29.01 |
| ray_laptop | henrys: iirc, fill_adjust is not in the image_enum it's in the gs_imager_state_common | 17:29.36 |
| Robin_Watts | http://ghostscript.com/~regression/robin/ <- That's a bmpcmp run without any special treatment of Type3s. | 17:30.07 |
| henrys | ray_laptop:well we know it is available when images are decimated to rectangles when else would you need it? | 17:31.03 |
| ray_laptop | henrys: the image code doesn't use fill_adjust. Just the fill and stroke code | 17:32.27 |
| | the image code uses the 'center of pixel' rule regardless of fill_adjust | 17:32.54 |
| henrys | I don't think that's true and fill adjust is gx_image_enum_s | 17:35.01 |
| Robin_Watts | ray_laptop: Currently the code isn't conditional (but I haven't committed it yet). | 17:36.56 |
| | Having it conditional may not be a bad idea. | 17:37.14 |
| henrys | from the image enum structure fixed adjust; /* adjustment when rendering characters */ | 17:38.40 |
| | | 17:38.41 |
| Robin_Watts | penum->adjust = | 17:42.30 |
| | (pim->ImageMask && pim->adjust ? float2fixed(0.25) : fixed_0); | 17:42.32 |
| | Voodoo! | 17:42.37 |
| henrys | and you were expecting less ? | 17:43.08 |
| Robin_Watts | My voodoo (generally) has comments explaining why pins are required. | 17:43.51 |
| | So penum->adjust is zero everywhere, except for when fill_adjust is non zero, and we're drawing an imagemask. | 17:54.12 |
| | when it's 0.25 | 17:54.24 |
| | no. let me try that again. | 17:56.18 |
| | penum->adjust is zero everywhere, except when pim->adjust=1, and we're drawing an imagemask, when it's 0.25 | 17:56.42 |
| henrys | ... except when pim->adjust is non-zero ... | 17:57.25 |
| Robin_Watts | pim->adjust is pickled into a single bit in gx_image1_mask_sput. | 17:58.10 |
| henrys | oh then I retract | 17:58.40 |
| Robin_Watts | I don't understand what that function is for, but pim->adjust is a bool, as far as I can tell. | 17:59.00 |
| | So sending pim->adjust = -1 is hard. | 17:59.20 |
| | but maybe I don't need to. | 18:00.02 |
| | If I'm only working on imagemasks, then I can take the pis == NULL case to mean I shouldn't apply my correction. | 18:00.47 |
| | then I can look at pis->fill_adjust directly. | 18:00.58 |
| | where in the code is it set to -1 for fonts, do you know offhand? | 18:01.20 |
| | (i.e. is it already set to -1 appropriately, or am I going to have to do that?) | 18:01.37 |
| henrys | type42_fill() | 18:02.40 |
| Robin_Watts | ok, so I'd need to do it for type3's. | 18:03.28 |
| henrys | I'm sure kens or chrisl could help with that. The font code has changed quite a bit since I've had my head in it and I don't want to lead you astray. | 18:04.58 |
| Robin_Watts | what are peoples thoughts on having this as being somehow conditional ? | 18:06.39 |
| chrisl | robin_watts: so you want a setting in the graphics/imager state? | 18:09.30 |
| Robin_Watts | I'm not sure how it'd be implemented. possibly, yes. | 18:10.11 |
| chrisl | Well, we don a bunch of setup before we render a glyph (of any kind), if you give me a minute I'll point you at where it's done | 18:10.48 |
| Robin_Watts | chrisl: What I need is for the start of type3 glyph processing to record the fill_adjust, and set fill_adjust to -1. And then the end of type3 glyph processing to set it back to what it was before. | 18:12.06 |
| ray_laptop | Robin_Watts: setting fill_adjust to 0 for Type 3's will change how strokes and fills paint | 18:12.33 |
| | or -1 or -3 or any funky value | 18:12.51 |
| Robin_Watts | ray_laptop: True. damn. | 18:13.19 |
| ray_laptop | if you have a graphics state, I think you should use the show_gstate or graphics_type_tag | 18:13.40 |
| Robin_Watts | I don't have a gstate, I have a pis. | 18:14.06 |
| ray_laptop | strange -- how does it manage to call the device fill_rect then ? | 18:14.48 |
| | Robin_Watts: for example, what function are you in ? | 18:15.24 |
| Robin_Watts | I'm in gx_image_enum_begin | 18:15.36 |
| ray_laptop | Robin_Watts: OK, so that has a 'dev' which will have the tag | 18:16.35 |
| henrys | well you would add special case code exactly where the type42 tests for -1 are. | 18:16.52 |
| | that's pretty easy. | 18:17.14 |
| ray_laptop | henrys: see above, I don't think fill_adjust can be messed with for Type 3 painting | 18:17.32 |
| | Robin_Watts: so since you have a 'gx_device', you have the graphics_type_tag -- all we have to do is fix it so that the text bit stays there until the glyph is done | 18:18.44 |
| | and you don't need the pis at all for that | 18:19.19 |
| henrys | ray_laptop:right in gxfill.c:318 you would check for your special case and make it do what it would have done without the hack. | 18:19.23 |
| ray_laptop | so even the pis == NULL case is OK, right ? | 18:19.32 |
| henrys | all this is getting crazy though. We haven't even tried to push back with Phil. You guys just want to make this change? | 18:19.58 |
| | we are in spec. | 18:20.22 |
| ray_laptop | henrys: we've been pushing back on this issue for years now with cust 531 and cust 700. If we have a way to 'fix' it, the issue would stop coming up. | 18:21.07 |
| henrys | alright. | 18:21.52 |
| ray_laptop | each time we have to try and get Acrobat to fail when rendering to some particular resolution (which isn't ever the same as when gs has the problem) and then we WONTFIX it, but the customers still aren't happy | 18:22.14 |
| | Robin_Watts: but I thought the problem with bug 692666 was that the fills were too big and overwriting the previous line -- how does changing the imagemask painting help ? | 18:24.45 |
| | or does your change make the imagemask bigger ? | 18:25.33 |
| Robin_Watts | sorry, was on phone. | 18:26.35 |
| | My fix makes the imagemask bigger. | 18:26.44 |
| ray_laptop | I see -- I thought you were gridfiting. So that makes the imagemask bigger because ... ? | 18:27.13 |
| Robin_Watts | Yes, I grid fit. | 18:27.25 |
| | The imagemask might go from 0.3 to 0.7 (vertical range). | 18:27.50 |
| | so I make it go from 0 to 0.99999999999 | 18:27.59 |
| | so it completely fills the pixel. | 18:28.08 |
| | In the case of the troubled file, it goes from 0.3 to 1.2 or something. | 18:28.28 |
| | so I make it go from 0 to 1.999999999999 and it fills 2 pixels. | 18:28.40 |
| ray_laptop | Robin_Watts: but the center of pixel is at 0.5 -- which is painted on both examples | 18:28.46 |
| Robin_Watts | In the second example, only the 0th pixel is filled without my fix; with it, both 0 and 1 are filled. | 18:29.17 |
| | so when the 0th pixel is overwritten by the next path painting operation, at least part of the image remains. | 18:29.42 |
| ray_laptop | Robin_Watts: ok, so you are 'rounding up' the size as well as adjusting the 'fit' | 18:29.51 |
| Robin_Watts | You say potato.... | 18:30.38 |
| | :) | 18:30.43 |
| chrisl | Robin_Watts: so, the gx_image_enum_s has an "adjust" field (I think henrys already mentioned that). You could set that to a "special value" in gs_image_enum_init (which has access to the graphics state, so can check for show_gstate). | 18:30.46 |
| ray_laptop | hmm... so it looks like you are making it use the 'any part of pixel' rule (for only the narrow dimension) | 18:31.04 |
| Robin_Watts | ray_laptop: basically, yes. | 18:31.18 |
| ray_laptop | chrisl: Robin_Watts: using the image_enum 'adjust' would be better than using the gstate fill_adjust | 18:32.50 |
| Robin_Watts | I've got it stopped here in an imagemask. pis->is_gstate = 1, and show_gstate is NULL. | 18:32.50 |
| ray_laptop | Robin_Watts: so is that painting a Type 3 ? | 18:33.18 |
| Robin_Watts | I believe so, but... | 18:33.34 |
| | let me run again with -dPDFDEBUG. | 18:33.41 |
| ray_laptop | call stack should say | 18:33.45 |
| chrisl | ray_laptop: I don't think so, the image call will come from the interpreter | 18:34.19 |
| ray_laptop | chrisl: Oh, that's right op_show does an interpreter call_out | 18:34.54 |
| Robin_Watts | yeah, I can't see a type3 thing in the callstack. I'd assumed there was lots of continuation stuff going on. | 18:35.02 |
| chrisl | Robin_Watts: what file is it? | 18:35.23 |
| Robin_Watts | -dPDFDEBUG -o out%d.ppm -r300 -sDEVICE=ppmraw ..\ghostpcl\tests\pdf\Bug6901014_Arioli-NAG-Warwick.pdf | 18:35.47 |
| | Page 20 | 18:35.49 |
| ray_laptop | Robin_Watts: the footprints would be in the interpreter exec stack (hard to look at with a debugger) | 18:35.56 |
| | you can force an error return and see the exec stack with -dESTACKPRINT | 18:36.37 |
| | but PDFDEBUG output is easier | 18:36.50 |
| chrisl | thinks a smaller file would have been better...... | 18:36.54 |
| Robin_Watts | OK. I see a Tj operator, then it looks like it's decoding a glyph (1 0 0 0 1 1 d1 etc) | 18:37.01 |
| | So this is an inline imagemask as part of a type3 glyph. | 18:37.28 |
| | actually, that's working. | 18:39.11 |
| | sorry. | 18:39.15 |
| ray_laptop | Robin_Watts: so is the GS_TEXT_TAG set in the dev->graphics_type_tag ? (there is a funky heuristic - aka hack -- in gspaint.c that tries to detect the type to text sometimes) | 18:40.23 |
| Robin_Watts | Trying now. | 18:43.19 |
| | dev->graphics_type_tag = 2 | 18:45.18 |
| | so, image. | 18:45.32 |
| | (but this is drawing into the cache, so we expected that to be wrong,currently) | 18:46.09 |
| ray_laptop | Robin_Watts: correct since gs_image_begin_typed sets it without preserving the GS_TEXT_TAG. | 18:47.09 |
| | and we don't un-set the GS_TEXT_TAG bit when done with the *show operation | 18:47.49 |
| | i.e. in op_show_continue_dispatch in the 'all done' case (case 0) | 18:49.50 |
| | if we are painting to a cachedevice, it'll have its own graphics_type_tag so that case doesn't actually have to un-set it, but for uncached glyphs, we do have to | 18:51.15 |
| | I'm going to coffee -- bbiab. | 18:52.06 |
| Robin_Watts | Its an easy fix, but I don't think we've agreed what the right thing to set is. | 18:52.19 |
| henrys | I was just going out myself | 18:52.26 |
| | as we all leave Robin_Watts holding the bag ... | 18:52.51 |
| chrisl | Hmm, my window manager keeps dying for some reason...... | 18:59.08 |
| | Robin_Watts: have you got enough info to give you *some* route forward? | 19:00.15 |
| Robin_Watts | Well, I have something that should work. | 19:01.22 |
| | (Using the show_gstate) | 19:01.43 |
| chrisl | OKay, it's just with a window manager that's intermittently dying, I think I'm going to finish now - before it gives me a headache! | 19:02.09 |
| Robin_Watts | night | 19:03.04 |
| mvrhel | bye chrisl | 19:03.14 |
| chrisl | mvrhel: night | 19:03.55 |
| henrys | tor8:can you tell me the status of annotations in mupdf - I recally there being support or some sort of API right? | 19:28.21 |
| tor8 | we load annotations that have appearance streams, we toggle rendering them based on their "usage" target | 19:29.33 |
| | pdf_run_page_with_usage(...., "Print") for example | 19:29.46 |
| | we also load link annotations and expose an api to get their extent on the page and their destination | 19:30.37 |
| henrys | so there are callbacks so the client can do something gui like ... | 19:31.13 |
| mvrhel | bbiab. kids only have 1/2 day todya | 19:32.08 |
| ray_laptop | Robin_Watts: I thought you had show_gstate == NULL ? | 19:32.26 |
| tor8 | henrys: we don't use callbacks in mupdf. | 19:34.18 |
| | mupdf doesn't drive things, it's just a library that does what you tell it to | 19:35.03 |
| ray_laptop | it would be up to the client to detect clicks that are on a link and do something | 19:38.09 |
| | tor8: can the client select a different appearance for an individual annotation (to support something like 'mouseover' changing the appearance) ? | 19:39.09 |
| Robin_Watts | ray_laptop: Between me and MSVC I got it wrong. | 19:41.07 |
| ray_laptop | Robin_Watts: the show_gstate ? so it wasn't NULL ? | 19:41.42 |
| | tor8: to use the PDF terminology, to select the normal, rollover or down appearance ? | 19:43.52 |
| henrys | tor8:I'm afraid we really do need some documentation for all this, something along the lines of ghostscript api documetation API.htm | 19:47.50 |
| | crickets ;-) | 19:48.43 |
| ray_laptop | I have to run to the music store. bbiab. | 19:50.04 |
| henrys | I'm moving from coffee shop back home. | 19:50.37 |
| | tor8:I wonder if anyone would be interested doing the documentation as a consulting project? | 20:07.08 |
| vtorri | hey | 20:28.34 |
| | is it possible to edit pdf with mupdf ? | 20:28.43 |
| tor8 | ray_laptop: not at the moment, but it would be very easy to add | 20:29.07 |
| | the problem is you have to rerender the whole page unless we render annotations to separate image buffers | 20:29.33 |
| vtorri | tor8: i'm wondering if you ansered really to ray_laptop or me :) | 20:29.55 |
| tor8 | vtorri: not extensively. see pdfclean for what you can do. | 20:30.07 |
| vtorri | tor8: ok | 20:30.21 |
| | thanks | 20:30.25 |
| egeriis | Hi there. I am having some trouble getting readable text from my PDF to JPEG conversion with ghostscript. Is there any way to enhance the output? | 21:25.20 |
| tor8 | don't use jpeg? | 21:35.26 |
| | -dTextAlphaBits=4 | 21:35.43 |
| mvrhel | darn. GC is biting me in my quest for unmanaged color | 21:49.59 |
| | or actually just making things a bit more complex | 21:52.37 |
| Robin_Watts | egeriis: Using JPEG for stuff that contains text is a bad idea. | 22:01.36 |
| | Far better to try something like png16m. | 22:01.45 |
| henrys | tor8:well we have an important customer coming up that wants "annotation support" - I didn't speak with them so I don't have anything more specific than that - seems like we need to flesh out more requirement details to understand if we have what they need. | 22:01.59 |
| egeriis | Robin_Watts: Yep. But that's not the issue here. It seems like Ghostscript would like to antialias some of the text, but only a small part. | 22:03.26 |
| | tor8: -dTextAlphaBits=4 actually helped a bit, but only on the part that GS already recognized as text. Or whatever it is that's wrong... | 22:03.54 |
| tor8 | you can use -dGraphicsAlphaBits=4 as well, for line art | 22:04.20 |
| Robin_Watts | If there is text that isn't being improved by -dTextAlphaBits, then perhaps it's not sent as text, but rather as graphics... so what tor8 said. | 22:04.42 |
| tor8 | henrys: as long as they don't want annotation *editing* support we should be able to provide | 22:04.55 |
| egeriis | Check this out: http://ebinder.dk/pdf-2.png | 22:05.11 |
| | tor8: Tried that, it didn't seem to have an effect :( | 22:05.20 |
| tor8 | egeriis: yeah, that's un-antialiased text alright | 22:05.39 |
| | you could try rendering at 4x the size and downscale with imagemagick (or something similar) | 22:05.53 |
| Robin_Watts | tor8, henrys: We can probably even cope with adding/removing annotations - as long as they are prepared to generate the appearance stream themselves. | 22:06.44 |
| egeriis | Not really a stable solution. As you can see it's like some of the text is not even readable. | 22:07.20 |
| | How do I render at a higher size, would like to see how the "graphics" look then. | 22:07.41 |
| Robin_Watts | egeriis: Try using -sDEVICE=tiffscaled -o out.tif -r600 -dDownScaleFactor=3 | 22:08.02 |
| | That will render at 600dpi then downscale to 200dpi. | 22:08.20 |
| | henrys, ray_laptop etc: http://ghostscript.com/~regression/robin/ | 22:11.11 |
| | Anyone offended by the diffs we see there? | 22:11.22 |
| egeriis | Robin_Watts: Wow, look at that: http://ebinder.dk/pdf2-2.png | 22:11.47 |
| | Do you have any idea why it ain't antialiased at all? | 22:12.28 |
| Robin_Watts | Not offhand, no. | 22:13.09 |
| egeriis | For reference, the full command: gs -dBATCH -dNOPAUSE -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -dDOINTERPOLATE -dAlignToPixels=1 -sDEVICE=png16m -sOutputFile=pdf2-%d.png -r216 -dDownScaleFactor=3 Scan10006.PDF | 22:13.10 |
| henrys | if someone says they want support for annotations - I have to assume that includes adding and editing of comments to the pdf. But we'll see after I have a chance to speak with them. | 22:13.45 |
| Robin_Watts | henrys: as I say, I think it's doable, within reason. | 22:14.44 |
| egeriis | Robin_Watts: Thank you for your help, this has been a huge headache for me the last couple of days. You made my evening :) | 22:36.20 |
| henrys | Robin_Watts:I looked at the first page it all looks reasonable. | 22:41.12 |
| henrys | adds mupdf api documentation to the meeting agenda | 22:42.04 |
| pipitas | Hi all | 22:51.34 |
| | I have a problem building Ghostscript from a Git checkout. (This is Ubunut Oneiric 32bit). | 22:52.05 |
| | The error messages from make are here: http://pastebin.ca/2095095 | 22:52.24 |
| | I'd be grateful to anybody willing to look at it and give me hints how to solve this. | 22:52.59 |
| henrys | pipitas:and you can build an earlier release? | 22:53.54 |
| | seems like HAVE_SYS_TIME_H should be 1 | 22:58.09 |
| pipitas | henrys: I could build every weekend on this system until last Sunday. Then it failed the first time. I never re-ran configure or "make clean". However, now I cleaned and did re-run configure, but to no avail.... | 23:00.21 |
| henrys | so obj/gconfig_.h does not have HAVE_SYS_TIME_H? | 23:02.04 |
| pipitas | checks... | 23:02.16 |
| | Hmm... I don't find a file called gconfig_.h | 23:04.10 |
| henrys | than I'm not sure how time_.h compiles it has #include "gconfig_.h" | 23:05.17 |
| pipitas | I also now see that configure throws an error: | 23:05.47 |
| | config.status: error: cannot find input file: `cups/pstopxl.in' | 23:05.49 |
| henrys | I hope this hasn't recently changed. | 23:05.51 |
| | so maybe configure error'd out before it created the configuration file that would make sense, your error doesn't make sense though, you have a compile error after #include gconfig_.h which you say doesn't exist. | 23:08.01 |
| pipitas | Oh, I found obj/gconfig_.h now... It has only 1 line saying: "#define HAVE_DIRENT_H" | 23:08.09 |
| henrys | okay now I'm with you. | 23:08.26 |
| | I remember some change about pstopxl now what the heck was it? | 23:11.05 |
| | probably best to just report a bug to chrisl he can fix it tomorrow. | 23:11.38 |
| pipitas | henrys: so far I did "make clean" only in the ghostpdl/gs/ subdir. Could it help to do that in the parent, ghostpdl/ ? | 23:12.42 |
| henrys | wow what a coincidence | 23:13.13 |
| chrisl_r61 | No looking at the logs..... | 23:13.23 |
| | pipitas: you need to rerun autogen.sh | 23:13.34 |
| henrys | it seemed a bit too coincidental | 23:13.39 |
| chrisl_r61 | I shouldn't really "have a quick look" before I go to bed! | 23:14.00 |
| pipitas | henrys: my working assumption was that I may be doing something wrong... Because you guys compile more often than I do and would probably have fixed it since Sunday if it was a GS build system bug? | 23:14.00 |
| | chrisl_r61: thanx, will try | 23:14.16 |
| henrys | pipitas:I hate to say it but I never trust make clean I always blow away the object directory. | 23:15.11 |
| chrisl_r61 | pipitas: to be honest, I don't use Oneiric for Ghostscript work - I happen to have it on a couple of latops, but I don't build on it regularly. | 23:15.52 |
| pipitas | configure error gone already after running autogen.sh | 23:17.09 |
| | now waiting for make result | 23:17.21 |
| henrys | I think running autogen.sh is expected when you pull from the source code repo in most projects. For tarballs just "configure" | 23:20.22 |
| | thanks for checking in chrisl_r61 don't let us keep you up. | 23:21.29 |
| chrisl_r61 | I'll stick around until pipitas confirms he's up and running - otherwise I'll never get to sleep! | 23:22.03 |
| pipitas | chrisl_r61: thx .... make should be done in a short while now | 23:22.43 |
| | chrisl_r61: yes, make completed without mistake after 6m56sec | 23:23.24 |
| | thanks a lot for your help | 23:23.30 |
| chrisl_r61 | pipitas: cool. As henrys said, you need to be ready to run autogen.sh when you pull source from the repository | 23:23.54 |
| | Okay, I can turn in with a clear conscience ;-) Night folks..... | 23:24.51 |
| pipitas | henrys: I must have run autogen.sh many months ago, and after that only "git pull; make" (and meanwhile forgot about autogen.sh altogether) | 23:25.52 |
| | Thanks again. | 23:26.52 |
| pipitas | goes to bed too now | 23:27.18 |
| henrys | take care pipitas | 23:30.47 |
| | Forward 1 day (to 2011/11/24)>>> | |
IRC Logs
