| | <<<Back 1 day (to 2012/05/31) | 2012/06/01 |
| mvrhel | ok. looks like my overprint simulation color witchcraft with the RGB device and black ink is working | 01:41.47 |
| | looks like I may have one clist issue though | 01:43.26 |
| | dig into that tonight | 01:43.32 |
| paulgardiner | tor8: For text layout I need various measurements from the font: specifically need to measure specific chunks of text and need space width. Previously I've rendered a scaled up version to the bbox device, but I'm guessing that's not the best way. | 10:05.39 |
| | pdf_show_char seems to be where the movement from one char to the next is calculated... I think. | 10:07.32 |
| Robin_Watts | paulgardiner: If you're talking width measurements, then the PDF layer should have all the information you need. | 10:07.43 |
| tor8 | paulgardiner: right. we don't have much in the way of getting font advance widths for pdf since we don't really need it. and the xps interpreter has an ugly hack that just calls freetype directly. | 10:07.54 |
| Robin_Watts | (as pdf files have to contain the widths for the font) | 10:08.01 |
| tor8 | we should probably hoist that up into a proper set of functions for fz_font | 10:08.20 |
| Robin_Watts | If you want a bbox (as I imagine you may well want when you are doing multiline stuff) then you'll need to involve freetype. | 10:08.47 |
| tor8 | paulgardiner: xps/xps_glyphs.c in xps_measure_font_glyph | 10:08.52 |
| Robin_Watts | And as tor8 says, we ought to make that a pdf layer interface. | 10:09.01 |
| | oops. an fz level interface. | 10:09.13 |
| paulgardiner | Ok. I'll take a look - see if I can suss what needs doing. | 10:10.10 |
| | So the code in xps_glyphs.c is likely to handle all the case that occur in pdf? | 10:11.23 |
| tor8 | paulgardiner: depends on what you need, really. | 10:11.45 |
| | the xps_glyphs code only handles freetype based fonts | 10:11.57 |
| | the pdf interpreter uses a pdf_font_desc wrapper to deal with font substitution and overridden font metrics and encodings | 10:12.31 |
| | so if you're going to use this to synthesize appearance streams then I think we'll need to do one of two things: | 10:13.18 |
| | 1) reuse the existing font descriptor, and potentially deal with funny encodings | 10:13.53 |
| | 2) make a new font descriptor in a format we know works, based on the base 14 fonts | 10:14.15 |
| | I think 2 is more work up front, but will save us headaches later on | 10:14.36 |
| | it's also the most predictable :) | 10:14.44 |
| | and in case 2 we can just go look at freetype for the advance widths | 10:14.59 |
| Robin_Watts | There is something to be said for Pauls current approach. | 10:17.18 |
| | by rendering the appearance stream to the bbox device you get an exact bbox, including borders etc. | 10:17.47 |
| | but I guess you need the measurements to make the appearance stream in the first place. | 10:18.05 |
| tor8 | Robin_Watts: but you need some form of font metrics to place the glyphs | 10:18.16 |
| paulgardiner | Well, not necessarily | 10:18.21 |
| | I seem to be getting away with it at the moment | 10:18.48 |
| | the default appearance stream sometimes specifies 0 as the font size and then one has to adjust size to fit the box. I have that working on the basis of measuring using the bbox device. | 10:20.17 |
| tor8 | This is what I had in mind, feel free to disagree: | 10:20.44 |
| | Step 1: Synthesize known font descriptors for the base 14 fonts, to use when creating appearance streams. | 10:20.51 |
| | Step 2: Add metric and kerning query functions to fz_font (for both FT and Type3 cases) | 10:20.52 |
| | Step 3: Add a rudimentary text layout function to fz_text. | 10:20.52 |
| | Step 4: Turn fz_text object back into pdf appearance streams. | 10:20.52 |
| | step 3 would be able to create a single line (or line wrap on spaces, given a max width) of text in a single font and size | 10:21.59 |
| | the fz_text contains both laid out text and a unicode variant, so it may be suitable for use in the text widget code | 10:23.01 |
| | not that I suggest you shoe horn it in if it doesn't fit; converting on the fly for display is fine too | 10:23.38 |
| | otoh, steps 3 + 4 may be trouble because we can't rely on step 1 having been done | 10:26.16 |
| | and then we get into encoding trouble again | 10:26.26 |
| paulgardiner | It was in the hope of getting that sort of suggestion that I was asking about this, but now seeing how much work is involved I'm wondering whether my worries about the current approach of rendering to the bbox device may be invalid. I was worrying that I might still be doing per-pixel work even with the bbox device and that I may not be able to measure things like space that have no rendered... | 10:26.49 |
| | ...output. | 10:26.50 |
| | Any per-pixel work would be bad because I scale up a lot while measuring to get accuracy - the result being an integer bbox | 10:27.56 |
| tor8 | paulgardiner: I think we can get something working with just step 2 (adding metric queries to fz_font) | 10:27.59 |
| | I'd like step 1 to guarantee we always get predictable results on the output (regardless of broken embedded fonts, encodings it uses, etc) | 10:28.37 |
| | but as you say, you've only ever seen /Helv used :) | 10:28.55 |
| | yes, I don't think measuring glyphs by the bounding box is a good idea | 10:29.49 |
| | the spacing will look really odd! | 10:29.56 |
| | paulgardiner: if you want I can see about making a fz_measure_glyph function? | 10:30.29 |
| paulgardiner | Ah, well I wasn't measuring individual glyphs. | 10:30.31 |
| tor8 | right, you're measuring words or some such? | 10:31.15 |
| | how do you position the glyphs inside the word? | 10:31.25 |
| paulgardiner | So far sentences, but for multiline I need to measure words and space | 10:31.40 |
| tor8 | also, some embedded pdf fonts don't have a space glyph at all | 10:31.42 |
| Robin_Watts | I'm inclined to think we need a function that goes something like: Here is a string, and a maximum width. Tell me the maximum number of chars from that string that I can fit into the width, and the width of that number of chars. | 10:32.13 |
| paulgardiner | Oh yes | 10:32.23 |
| | That would be ideal | 10:32.28 |
| tor8 | paulgardiner: are you working with the pdf_font_desc or fz_font? | 10:33.02 |
| paulgardiner | Although just being able to measure words and deriving the space skip would be enough. | 10:33.07 |
| Robin_Watts | tor8: They may not have a space glyph, but they must have a space 'width', right? | 10:33.13 |
| tor8 | Robin_Watts: nope. | 10:33.19 |
| Robin_Watts | Then should we forbid people entering glyphs that we have no space for ? | 10:33.39 |
| | or do we fallback to a base font on a per glyph basis? | 10:33.50 |
| tor8 | Robin_Watts: I've seen plenty of files with neither. which is why I think for sanity sake we should limit text input to the base 14 fonts and make our own font descriptor for them. | 10:34.06 |
| paulgardiner | tor8: I've only just started looking at this. Those are the two places I've identified but I hadn't felt I knew where to work | 10:34.19 |
| Robin_Watts | How about, let people input in any font they want, but the moment they need a glyph that we don't have in that font, we drop back for the entire string? | 10:34.49 |
| tor8 | paulgardiner: when you're synthesizing the appearance stream, I mean. I think you have the pdf_font_desc and that is the easiest place to add what you want (since it takes care of both widths and encodings) | 10:35.03 |
| | Robin_Watts: or we can hack it for the space character, like the spec does | 10:35.33 |
| | and if there is none in the font, just use 0.2 * fontsize or something like that | 10:35.50 |
| Robin_Watts | Ah, ok. | 10:35.54 |
| | That could be done within the stringmeasure function. | 10:36.09 |
| paulgardiner | tor8: At the moment I get away without either because I call pdf_run_glyph passing in a resource dict | 10:36.39 |
| tor8 | there's a funky special case for character encoding 32 where the interpreter uses the 'wordspace' gstate variable | 10:36.51 |
| | regardless of what's in the actual font | 10:36.57 |
| paulgardiner | The fzbuf has the Tf in the string before the text | 10:37.11 |
| tor8 | paulgardiner: oh, right... the really hacky solution :) | 10:37.41 |
| | but if you have the Tf name and font size you can find the pdf_font_desc in the resource dictionary | 10:38.00 |
| paulgardiner | Oh yes. As hacky as possible :-) | 10:38.01 |
| tor8 | and then do the metrics based on that | 10:38.08 |
| paulgardiner | tor8: yep | 10:38.12 |
| | I had looked at that, but I was unsure which fields were guaranteed defined | 10:38.32 |
| tor8 | and I guess you're assuming the encoding is "sane" enough to just work with ASCII :) | 10:38.37 |
| paulgardiner | there's htmx, but is that tt specific? | 10:38.48 |
| | And there's widths, but I was uncertain if that is present unless widths are overridden in the PDF file | 10:39.34 |
| tor8 | the hmtx (horizontal metrics) are set for all pdf font descriptors, so that's where you should get them | 10:39.47 |
| paulgardiner | Ah right. Then it may be easy. Great | 10:40.07 |
| tor8 | paulgardiner: pdf_show_char calls pdf_lookup_hmtx to find the advance width | 10:40.54 |
| paulgardiner | he he. I was just looking at that function to try to figure out where it got the skips from but got a bit lost in the detail. | 10:42.08 |
| tor8 | it's a bit nasty. thank the spec writers for that :) | 10:42.36 |
| | so basically it gets the default character width (from the encoding code point, not the glyph id) from the Widths array in the font descriptor | 10:43.11 |
| | these metrics are baked into the hmtx table in our pdf_font_desc | 10:43.34 |
| | it then adjusts that by the font size and adds the 'charspace' constant from the gstate | 10:43.55 |
| | and if it's character 32 it also adds the 'wordspace' constant | 10:44.21 |
| paulgardiner | So I should be able to base a measure function on that behaviour. Where should it go? pdf_interpret.c, so that it can share subfunctions easily, or does it not make sense there? | 10:46.28 |
| tor8 | pdf_font.c I think is the most natural place for it. if you even need one, given that pdf_lookup_hmtx is basically what you need :) | 10:47.24 |
| | a function that wraps a loop around pdf_lookup_hmtx that takes a utf-8 string should be in pdf_font.c I think | 10:47.50 |
| | but I worry about encodings (as you can notice, I keep bringing it up) | 10:48.22 |
| paulgardiner | Ah yes. Of course. Ta | 10:48.22 |
| tor8 | pdf_interpret would make some sense too, I guess. living near its relatives and all that :) | 10:49.26 |
| paulgardiner | How bad is it to worry about encodings later? Might I do something that will later make handling encodings difficult? | 10:49.28 |
| tor8 | at the moment you're relying on the encoding being some sane subset of unicode/ascii | 10:49.57 |
| | but maybe in some japanese tax form all the forms and fonts are using S-JIS instead :) | 10:50.30 |
| | as long as the assumption that the encoding is a sane subset, we should be fine. we can also make sure that it is, by creating our own fonts based on the base 14 rather than using the ones supplied by the file (or a quick check that we can use the file's fonts by looking at the /Encoding etc) | 10:51.55 |
| paulgardiner | I'm not against handling the encoding properly, but I just hoped that it would be possible to update it later. | 10:53.21 |
| | Thinking it through is good of course, but I'm struggling to remember how the different encodings work. | 10:54.02 |
| tor8 | I think it makes sense to assume we can always use unicode. but it sort of depends what the spec says to use when for the javascript API | 10:54.09 |
| paulgardiner | I should know really. I did most of the encoding work (and font interpretation) for Picsel's PDF agent, but it was a long time ago. | 10:54.37 |
| tor8 | if javascript mandates unicode, that means we can stop worrying for now, and eventually double check that our font descriptors are fine | 10:54.51 |
| | if the spec says to use whatever encoding happens to be used in the font... we're in for some trouble regardless | 10:55.51 |
| paulgardiner | My feeling is it may not look so difficult when everything else is in place... but of course there is the risk of making bad decisions early if not considering it. | 10:58.59 |
| tor8 | paulgardiner: we have a long history of ripping things up and redoing them completely in mupdf, so don't sweat it :) | 11:00.01 |
| | rather, get used to redoing things over and over until they fit :P | 11:00.13 |
| paulgardiner | Thank god for that. I've seen the result of "We can't rewrite this. We must patch it to make it work"! | 11:01.09 |
| tor8 | it helps that it's still a fairly small code base | 11:01.25 |
| paulgardiner | Yes very true | 11:01.42 |
| tor8 | with few interdependencies. but robin's been hard at work adding those in with the context and locks :( | 11:01.44 |
| Robin_Watts | Hey, I'm really happy with the way all that worked out. I think it was a much smaller impact than it might have been... | 11:02.33 |
| tor8 | Robin_Watts: yes. it's more appealing than I at first feared it might turn out :) | 11:02.55 |
| | for mupdf I've tried to make things out of independent components that are plugged together at the top level | 11:03.13 |
| Robin_Watts | OK. I can't put it off any more. time to start debugging through the gs transparency stuff... | 11:03.16 |
| tor8 | Robin_Watts: my sympathies. | 11:03.28 |
| paulgardiner | I don't think the context loses much of keeping things independent. | 11:03.50 |
| tor8 | paulgardiner: nope, not really. it's added a dependency on the exception stack everywhere, but that's such a pervasive thing it doesn't really matter | 11:04.37 |
| paulgardiner | The single thing I'd change is how many structures are visible over many files. | 11:04.48 |
| | I ran into that as a problem yesterday when I found xobject had me and contents. I has to search the whole code base for ->contents and ->me because the struct was visible | 11:05.38 |
| tor8 | paulgardiner: by making fewer and bigger source files, or adding a lot of accessors? | 11:05.46 |
| | yeah. that can be a bit of a hassle. | 11:06.10 |
| paulgardiner | tor8: I see your point. Accessors are a pain when all they do is return a field | 11:06.28 |
| tor8 | not so much if you're familiar with all of the code, but soon I'm not in that boat either, what with you and robin chipping in a lot of new code :) | 11:06.55 |
| paulgardiner | I don't know really. Swings and roundabouts | 11:06.57 |
| tor8 | ideally the types would be all opaque and all their functions live in one file | 11:07.19 |
| Robin_Watts | paulgardiner: You know that in VS you can right hand click on things and "show definition" and "show declaration" right? | 11:07.22 |
| tor8 | but then you've got places where things don't fit neatly into compartments | 11:07.30 |
| Robin_Watts | (Never used to work in Picsel projects, but...) | 11:07.33 |
| | (and "Find all references") | 11:08.37 |
| paulgardiner | Robin_Watts: yes I have used that. | 11:09.29 |
| Robin_Watts | I use that *all* the time. Miss it massively when I have to work on linux. | 11:09.59 |
| paulgardiner | Can't remember why I didn't use that for ->contents. That would have been better | 11:10.03 |
| tor8 | Robin_Watts: cscope does much of the same thing on linux | 11:10.53 |
| Robin_Watts | Aha. | 11:23.25 |
| | gsave/grestore does not save/restore the blendmode, I think. | 11:23.36 |
| | Sanity check: Can someone look at tests_private/comparefiles/Bug689422.pdf in acrobat and gs please? | 13:31.43 |
| kens | 1 minute | 13:35.06 |
| | OK what's the problem Robin_Watts | 13:37.09 |
| | ? | 13:37.11 |
| Robin_Watts | They look different for me. | 13:37.24 |
| kens | Hmm the Acrobat overpritn preview doesn't. | 13:37.45 |
| Robin_Watts | Ah! | 13:37.54 |
| kens | I wonder why | 13:38.06 |
| | Acrobat thinks it shuoldn't overprint | 13:38.46 |
| Robin_Watts | How do you get overprint preview? | 13:39.46 |
| kens | Its in 'output preview' | 13:39.56 |
| | THere's a check box | 13:40.01 |
| | In the advanced menu or toold depending on your version of Acrobat | 13:40.15 |
| | Hmm, there's transparency in that file | 13:40.38 |
| | Maybe its not overprinting really | 13:40.48 |
| Robin_Watts | Ok, so I go to Advanced -> Print Production -> Output Preview | 13:41.51 |
| | I still don't see the green circle through the red. | 13:42.03 |
| | mupdf agrees with acrobat. | 13:42.31 |
| | but gs shows the green circle through the red. | 13:42.42 |
| | Are you seeing the same thing ? | 13:43.05 |
| kens | Pahe is transparent, contains a form (with transparency group) which draws an image, which is actually another form, with a transparency group, which draws another form (with a transparency group) which draws another form with a transaprency group, which does some drawing in RGB, Then we draw another form with transparency group which fills a rectangle with a pattern | 13:44.00 |
| | Surprise! Its a cairo produced file | 13:44.27 |
| | There is no overprint, but I am unable to decide which is correct. I suspect Ghostscritp is incorrect, as I see no real transparency in the file. | 13:44.57 |
| Robin_Watts | yes, it's a horrible file. But... do you see the same gs/acrobat mismatch as I do? | 13:45.06 |
| kens | GS looks like it is overprting, Acrobat doesn't | 13:45.27 |
| | But I can't tell which is right | 13:45.39 |
| | Oh, and the 'real' image has a soft mask | 13:45.48 |
| Robin_Watts | overprinting? What I see looks like transparency. | 13:45.51 |
| kens | overprinting is a kind of crude transparency | 13:46.07 |
| Robin_Watts | There is a transparency group in the file, with an transparency of 0.5 | 13:46.23 |
| | I think gs is just getting it wrong. | 13:46.39 |
| kens | There is a constant alpha of 0.5 | 13:46.48 |
| | But that is the cricle | 13:47.06 |
| | circle | 13:47.10 |
| | The ocerlying object has a ca of 1 | 13:47.30 |
| Robin_Watts | Yes, like I say, I think gs is getting it wrong. | 13:47.50 |
| kens | I said that too, above | 13:48.02 |
| Robin_Watts | ok, thanks. | 13:48.16 |
| kens | There doesn't appear to be any 'real' transparency | 13:48.18 |
| | I don't really count a ca of 0.5 with no underlying object :) | 13:48.35 |
| Robin_Watts | Well, it means that rather than rendering to 0 1 0 it will render to 0.5 1 0.5 | 13:48.58 |
| | as the white background will show through the green. | 13:49.25 |
| kens | Really ? I thought it would render to 0 0.5 0 | 13:49.27 |
| | Robin_Watts : yes but the same effect could be gained with just setting a different colour | 13:49.44 |
| Robin_Watts | indeed. | 13:49.50 |
| | (in rgb white = 1 1 1, right?) | 13:50.00 |
| kens | Yes, good point | 13:50.13 |
| | Was thinking in CMYK today | 13:50.25 |
| Robin_Watts | Let's see how much I can simplify this file and still have it go wrong. Thanks kens. | 13:51.34 |
| kens | np | 13:51.41 |
| marcosw_ | henrys: I'm going through the recent bugs, nothing interesting so far, so we probably won't need to meet. | 16:36.29 |
| henrys | oh good | 16:38.03 |
| Robin_Watts | mvrhel: ping | 16:44.27 |
| mvrhel | good morning | 17:18.25 |
| Robin_Watts | Morning mvrhel | 17:18.56 |
| | Got an odd one here. | 17:19.01 |
| | In staring at the bmpcmps I have found a file where gs renders it one way, and acrobat another. | 17:19.27 |
| | even before my changes. | 17:19.35 |
| mvrhel | no | 17:19.45 |
| Robin_Watts | and my changes then make it different again. | 17:20.06 |
| mvrhel | what file is it | 17:20.21 |
| Robin_Watts | So I figured I'd try and understand what was going on. | 17:20.22 |
| | tests_private/comparefiles/Bug689422.pdf | 17:20.46 |
| | but I have a simplified version. | 17:21.08 |
| mvrhel | oh | 17:21.16 |
| | I made that file | 17:21.18 |
| Robin_Watts | hehe | 17:21.33 |
| mvrhel | or rather I had created some files based upon that one | 17:21.38 |
| Robin_Watts | http://ghostscript.com/~robin/circle.pdf | 17:21.49 |
| mvrhel | this was a pattern transparency bug that lead to the work in the transparency for patterns | 17:21.57 |
| Robin_Watts | no patterns involved now. | 17:22.08 |
| mvrhel | well thats no fun | 17:22.14 |
| Robin_Watts | No fun is one way to describe this :/ | 17:22.27 |
| | We have a transparency group (RGB, Knockout) in which we draw a solid green square and another transparency group, B. | 17:23.21 |
| | B is an RGB transparency group that contains an image C | 17:23.50 |
| | C is an RGB image with a softmask. | 17:24.03 |
| mvrhel | ok | 17:24.49 |
| Robin_Watts | The net effect of the C (as far as I can tell) is that draws a red triangle at 50% opacity. | 17:24.51 |
| | So I'd expect to see a green square with a red triangle overlaid transparently on it. | 17:25.22 |
| | And that is indeed what gs shows. | 17:25.26 |
| | Acrobat has the red triangle as solid though. | 17:25.57 |
| | so I'm confused. | 17:26.05 |
| mvrhel | well the main group is a knockout group | 17:27.20 |
| Robin_Watts | right. | 17:27.39 |
| mvrhel | so if you draw the red triangle group/object over the green is should blow away the green square parts yes? | 17:27.53 |
| | like what we do with the stroke and fill | 17:28.12 |
| Robin_Watts | which means, AIUI, that it will 'knockout' anything underneath that group when the group is written back. | 17:28.21 |
| | not that each subsequent thing drawn in the group will knockout the previous things in the group. | 17:28.45 |
| mvrhel | hold on let me read the spec | 17:28.46 |
| Robin_Watts | Or have I got that horribly wrong? | 17:28.53 |
| | Oh, I have got it horribly wrong. | 17:29.33 |
| mvrhel | The group can be knockout or non-knockout, determining whether the objects within its stack are composited with one another or only with the groupâs backdrop. | 17:30.08 |
| | perhaps this is a case where we dont handle the non isolated knockout | 17:30.49 |
| | recall there is a bug open for this | 17:31.02 |
| | so if the group is a knock out group, subsequent drawings within the group will get blown away | 17:31.46 |
| Robin_Watts | So if we have a blue background, and a knockout group on top of that, and in the knockout group I paint a transparent green object, then a transparent red object, whereever the red object paints, it should end up with red+blue, and no green. | 17:31.55 |
| mvrhel | depends if it is isolated or not | 17:32.26 |
| Robin_Watts | And indeed, the group in question is a non-isolated knockout group. | 17:32.36 |
| mvrhel | that is the issue | 17:32.43 |
| | i think we are fine with isolated | 17:32.50 |
| Robin_Watts | OK, that explains why gs differs from acrobat then. | 17:32.50 |
| | Thanks. | 17:32.55 |
| mvrhel | not not non-isolated knockout groups | 17:33.03 |
| Robin_Watts | ETOOMANYNEGATIONS | 17:33.42 |
| mvrhel | oh | 17:33.53 |
| | and not non-isolated | 17:33.57 |
| Robin_Watts | gotcha. | 17:34.05 |
| | Thanks. | 17:34.10 |
| mvrhel | maybe I will try to get that fixed after I get the copy_alpha stuff done | 17:34.30 |
| Robin_Watts | It dawned on me earlier gsave/grestore doesn't save/restore the blend modes or the opacity. | 17:35.34 |
| mvrhel | oh | 17:35.48 |
| Robin_Watts | and so I had to save them myself. | 17:35.51 |
| | and that dropped the number of diffs substantially. | 17:35.59 |
| mvrhel | I thought they were part of the extended graphic state | 17:36.03 |
| Robin_Watts | but I still have 500odd differences + a load of pdfwrite differences. | 17:36.14 |
| mvrhel | oh pdfwrite | 17:36.22 |
| | we need to *not* do this knockout push if we are going to a high level device | 17:36.38 |
| | there is some stuff in the pdf interpreter code related to this | 17:37.02 |
| | as far as knowing if we are going to pdfwrite | 17:37.12 |
| | it would be better to have a generic "high level" device | 17:37.25 |
| | we should add your file to Bug 692766 | 17:37.58 |
| | if you could | 17:38.00 |
| Robin_Watts | can you point me towards such code (or suggest something I can grep for) | 17:38.13 |
| mvrhel | hold on | 17:38.40 |
| Robin_Watts | done. | 17:38.52 |
| mvrhel | hmm the tests for use of pdfwrite were commented out | 17:41.32 |
| | it is an ugly hack | 17:41.42 |
| | currentdevice .devicename /pdfwrite eq | 17:41.44 |
| Robin_Watts | AH. | 17:41.56 |
| | .highleveldevice would be nicer - and that can call a devspecialop. | 17:42.30 |
| mvrhel | yes | 17:42.36 |
| | that would be a great idea | 17:42.50 |
| | or that is a great idea | 17:42.59 |
| Robin_Watts | Although, I suspect that's not a great test, because everyone has different ideas about exactly what constitutes a highlevel device. | 17:43.10 |
| mvrhel | well, true | 17:43.25 |
| Robin_Watts | Is a highlevel device something that doesn't rasterise? | 17:43.30 |
| mvrhel | but I would think xpswrite, pswrite, pdfwrite, would qualify | 17:43.46 |
| Robin_Watts | Right, but some of those can represent gradients and some can't, for example. | 17:44.07 |
| | I'd be more tempted by something like: "1 .devicecaps" to test if the devicecaps bit 1 is set. | 17:44.49 |
| | so we can extend the bits in future. | 17:45.08 |
| | 1 could mean 'doesn't rasterise', 2 could mean 'supports gradients', 4 could mean... | 17:46.44 |
| | supports pdfmarks or something. | 17:47.01 |
| mvrhel | I understand but I dont quite get the name devicecpas | 17:47.12 |
| | devicecaps | 17:47.15 |
| Robin_Watts | devicecapabilities | 17:47.21 |
| mvrhel | ah | 17:47.25 |
| Robin_Watts | sorry, lazy typist. | 17:47.32 |
| | henrys: You here? | 17:52.48 |
| | I see we have a dxdso_supports_hlcolor | 17:56.09 |
| henrys | yes | 18:05.47 |
| Robin_Watts | henrys: How would you feel about us gaining a new postscript operator, something like .devicecapabilities | 18:06.25 |
| | which would return an integer onto the stack. Each bit of the integer would indicate something about the capabilities. | 18:07.12 |
| henrys | yes didn't kens say he was eventually going to do something like that? | 18:07.17 |
| Robin_Watts | For now bit 1 being set would mean 'is a high level device'. | 18:07.29 |
| | And I'd implement it using a gxdso call. | 18:07.48 |
| | I could do with it now for the stuff I'm working on. | 18:08.02 |
| henrys | I'm fine with it I think you would get duplicating functionality arguments from others - ie use the parameter list. | 18:10.24 |
| Robin_Watts | henrys: So, every time we do a stroke, we should query the parameter list? | 18:11.46 |
| Robin_Watts | waves goodbye to performance. | 18:12.08 |
| henrys | I'm fine with the new operator and will fight the other on your behalf ;-) I think your argument doesn't hold up though - presumably a boolean could be set in the state and the parameter list could be invoked once, right? | 18:15.48 |
| Robin_Watts | henrys: So the pdf interpreter would, on every stroke, have to: | 18:17.03 |
| | query a value from the state. If it's there, then use it. If not, make the call to the operator, and store it in the state. | 18:17.46 |
| | which is a whole heap of push/pulling to the interpreter stack, if nothing else. | 18:18.12 |
| mvrhel | is the device changing with every stroke? | 18:20.18 |
| | I would think this would be a one time query | 18:20.28 |
| | it pertains to the actual target device | 18:20.58 |
| Robin_Watts | mvrhel: In the postscript code for the pdf interpreter, whenever we do a stroke, we need to know whether to use the funky knockout group or not. | 18:21.40 |
| mvrhel | right. | 18:21.48 |
| Robin_Watts | At the moment your code does: "PDFusestransparency" | 18:21.58 |
| | My code does: "PDFusestransparency .pathcomplexity 100 gt and" | 18:22.22 |
| mvrhel | so any device that supports transparency directly, we would not want to do such a push | 18:22.36 |
| | right now, the only device that does this is pdfwrite | 18:22.48 |
| Robin_Watts | And with this one we have to do: "PDFusestransparency .pathcomplexity 100 gt and <something else> and" | 18:22.56 |
| | The question is, what is the <something else>. | 18:23.12 |
| | I like: ".devicecapabilities 1 and" | 18:23.36 |
| mvrhel | the determination of if the target device supports transparency can be made at an earlier time, just like the knowledge that the source document has transparency | 18:23.50 |
| | which is encompassed in the PDFusestransparency | 18:24.08 |
| Robin_Watts | Is PDFusestransparency just a boolean value then ? | 18:24.52 |
| mvrhel | I believe so | 18:25.02 |
| Robin_Watts | I thought was a bound 'function'. | 18:25.23 |
| mvrhel | I can't see where it is going to go through and parse the file looking for transparency content with every stroke | 18:26.02 |
| | when it already did it | 18:26.32 |
| Robin_Watts | right, yes, good point. | 18:26.49 |
| mvrhel | the same is true for the real target device | 18:27.12 |
| | hopefully it will not change its capabilities | 18:27.20 |
| Robin_Watts | indeed. | 18:28.09 |
| | Well, I'm still going to implement a new operator and a gxdso, but I'll bind it nicely so it's only called once per page. | 18:29.33 |
| mvrhel | that sounds good | 18:29.50 |
| Robin_Watts | and if people want it done with the param list they can show me how :) | 18:30.00 |
| henrys | fair enough sorry I had a phone call. | 18:31.48 |
| | Robin_Watts:I have some pcl code in my local tree that uses the strcmp hack but it's isolated in one function and should be easy change. | 18:36.42 |
| | mvrhel:are you around? | 18:42.19 |
| mvrhel | yes. just wrapping up this overprint stuff | 18:42.34 |
| | seems to be working | 18:42.44 |
| henrys | quick question about 693055 | 18:42.55 |
| mvrhel | ok | 18:43.21 |
| henrys | each of those pcl6 commands is doing an srgb conversion. I wonder with a high level device like pxlcolor if the color should go straight through. | 18:44.43 |
| mvrhel | yes. I would think it should | 18:45.01 |
| | so with the srgb conversion, what is it converting to and from? | 18:45.30 |
| | from a gray to srgb or from srgb to a gray? | 18:45.41 |
| | even that should not change the things with our profiles | 18:45.55 |
| henrys | it's using the regular srgb profile | 18:46.11 |
| mvrhel | since they have the same gamma | 18:46.12 |
| | so what is the source color? rgb? | 18:46.31 |
| henrys | yes and an rgb device | 18:46.45 |
| mvrhel | so if we are doing rgb to rgb I don't see why it would be doing any conversions | 18:47.07 |
| henrys | the profile is just identity? | 18:48.06 |
| mvrhel | the combination of the two would be | 18:48.19 |
| | and we would skip any transformation | 18:48.28 |
| henrys | I thought I did see colors getting mapped with something different than identity with rgb devices let me check. | 18:49.31 |
| mvrhel | ok | 18:49.38 |
| henrys | I was probably looking at a file where the pcl explicitly fooled with the white point or something. | 18:56.54 |
| | anyway I'll look at that bug looks interesting. | 18:57.21 |
| mvrhel | ok. let me know if you need anything from me | 18:57.41 |
| | assuming I get this overprint stuff wrapped up for ray and cust 532 I am going to move to the AA issue with tiffsep | 18:58.23 |
| henrys | lucky you | 19:00.05 |
| | is rayjj_ about? | 19:00.40 |
| Robin_Watts | Testing a version of the patch with the pdfwrite detection in now. | 19:31.30 |
| mvrhel | ok. wacky overprint simulation is done. unfortunately no customer bug to close for that one | 19:38.40 |
| Robin_Watts | mvrhel: Make one! :) | 19:45.55 |
| scott-san | Robin are you on?? | 19:54.18 |
| mvrhel | scott is not patient | 19:55.07 |
| henrys | nor does he use irc names | 19:55.25 |
| mvrhel | hehe | 19:55.30 |
| | bbiaw | 20:10.06 |
| | Forward 1 day (to 2012/06/02)>>> | |
IRC Logs