| | <<<Back 1 day (to 2013/05/12) | 2013/05/13 |
| sebras | morning all | 08:54.21 |
| paulgardiner | hi | 09:00.37 |
| ghostbot | hey | 09:00.37 |
| Robin_Watts | morning | 10:08.39 |
| | I think I may finally have twigged to this pattern thing. | 11:24.59 |
| | At the moment a pattern is "made current", it keeps a copy of the parent gstate for the stream it's in (including the ctm etc). | 11:26.19 |
| | Specifically, it's on the scn. | 11:28.24 |
| kens | Is that just the ctm though ? Not the restof the gstate | 11:31.56 |
| Robin_Watts | kens: I believe it is the whole thing, but I am still experimenting. | 11:34.13 |
| kens | Hmm, that doesn't sound like what the spec says (but that doesn't stop Acrobat in other areas) | 11:36.58 |
| | BUt I thought you tried specifically setting the linewidth before executing the pattern, and it made no difference | 11:37.18 |
| Robin_Watts | kens: Right, but that's not the parent gstate. That would be the current gstate. | 11:37.48 |
| kens | Hmm. You said above that the pattern kees a copy of the parent gstate at the moment it is made current | 11:38.42 |
| | So I'm a bit unclear what you mean | 11:39.07 |
| Robin_Watts | Suppose I have a page stream, P which contains an object A. which calls another object B. | 11:39.22 |
| kens | Yeah, this is what I was wibbling about with forms and patterns | 11:40.04 |
| chrisl | I think it would be more accurate to say that the pattern inherits the grandparent gstate, wouldn't it? | 11:40.29 |
| Robin_Watts | let's call the gstate in force before P is run G. During P, it's H. H is the parent gstate for A, and during A it's I. | 11:40.31 |
| | I is the parent gstate for B, and during B it's J. | 11:40.42 |
| kens | Uh. | 11:41.00 |
| Robin_Watts | If the scn happens in P, then the pattern inherits G. | 11:41.42 |
| | If the scn happens in A. the pattern inherits H. | 11:42.05 |
| kens | If the pattern is run directly in the page, tehn the 'parent' gstate is the gstate at teh time the page begins. When the child object (lets say a form) is defined, it inherits the 'current' gstate. That gstate is then the 'parent' gstate ofr the pattern when it is executed in the context of the child object | 11:42.26 |
| tor8 | page sets state, calls xobject, calls pattern. for pattern, it's the state in play when the xobject call happened that should be used for CTM. | 11:42.44 |
| kens | Yes, and also the rest of the gstate I think | 11:42.58 |
| Robin_Watts | tor8: Right, EXCEPT, the thing we get wrong in mupdf, is that's it's NOT the parent gstate at the moment the pattern is drawn with. | 11:43.39 |
| | It's the parent gstate at the moment scn is called. | 11:43.47 |
| kens | I would have thought it was the parent gstate at the time the child objkect is executed. | 11:44.25 |
| tor8 | so it's the case of: page, xobject, "scn happens", another xobject, now draw something with a pattern? | 11:44.32 |
| Robin_Watts | tor8: In my test, I am changing between setting the scn in the page stream and in the first object, and yes, that makes a difference. | 11:45.21 |
| kens | Yes I would exepct it to make a differe3nce, because the 2 parents are different | 11:45.44 |
| | WHen you set scn in the page stream, the parent gstate is the gstate when the page stream begins. | 11:46.01 |
| tor8 | changing what between setting the scn and drawing? | 11:46.12 |
| Robin_Watts | I do the drawing always in the first object. | 11:46.25 |
| kens | When you set it in the xobject, I woudl expect the parent gstaet to be whatever the 'current' gstate is when the XObject is executed | 11:46.32 |
| Robin_Watts | kens: Indeed. | 11:46.41 |
| kens | Ah, so we are in agreement | 11:46.49 |
| | THis is what I would expect ot hgappen, but I don't believe its the 'scn' that triggers it | 11:47.03 |
| Robin_Watts | As I say, currently mupdf is using "the parent gstate of the stream when the object to be drawn with the pattern is drawn" | 11:47.45 |
| kens | WEhat chris suggested (and I'minclined to agree) is that whenever an 'object' which contains resources is evaluated, and the resource is a patterm, the pattern gets the current gstate | 11:47.55 |
| | Chris was suggestign this is how Acrobast works. | 11:48.13 |
| Robin_Watts | kens: Right, except we don't 'evaluate the resources' of an object. | 11:48.28 |
| | Let me test something else... | 11:48.44 |
| kens | Sure, I meant this is how Acrobat does it, and explains the awful hackery they added to the spec for this | 11:48.56 |
| chrisl | Robin_Watts: I assume mupdf parses the relevant resource dictionary before executing the stream object? | 11:49.35 |
| Robin_Watts | chrisl: Not necessarily, no. | 11:49.52 |
| | We hold a pdf object for the resources. | 11:50.00 |
| | but that might be an indirect pointer to the resources. | 11:50.12 |
| | so the resources themselves don't get resolved. | 11:50.25 |
| | resources get resolved lazily on use. | 11:50.38 |
| kens | So when we get a page from the pages tree, we look at its resources. If there is a pattern it defies the pattern then, using the 'current' gstate (which is the defauilt for a page). If during a page we execute an XObject, then we look at that XObject. If it has a pattern, then we defien the pattern again, this time using the current gstate (which is the gstate of the 'parent'', ie the XObject | 11:50.52 |
| | (when I say 'we' above, read Acrobat) | 11:51.15 |
| Robin_Watts | We can achieve exactly the same thing by storing a pointer to the parent gstate in the pattern when we resolve it (on the scn) | 11:51.46 |
| | which is nice, because it doesn't require us to change the way we work. | 11:52.14 |
| kens | You may need more than one pointer | 11:52.16 |
| Robin_Watts | kens: why? | 11:52.22 |
| tor8 | Robin_Watts: did we (before you started this work) get the ctm/topctm right, and just not the other gstate params? | 11:52.28 |
| kens | What happens if I define a page which uses a pattern, and a Form which uses the same pattern, then execute the form, then draw on the page with teh pattern | 11:52.44 |
| | The pattern needs two different gstates, one for the page and one for the form | 11:53.06 |
| tor8 | an uncolored pattern must get its color from the current gstate at invocation, not from the color set in the gstate at the parent level | 11:53.09 |
| | so if there's something saved from the pattern, it has to be a subset of the gstate | 11:53.31 |
| kens | says again, patterns are weird | 11:53.38 |
| tor8 | s/pattern/parent/ | 11:53.38 |
| Robin_Watts | tor8: The example that set me off on this road was one of line state being wrong. But in investigating it, I have since found one where the ctm is wrong too. | 11:53.40 |
| tor8 | which led me to assume it was only the ctm that needed messing about with | 11:54.04 |
| kens | No, there are lots of htings in the gstate which can change | 11:54.25 |
| Robin_Watts | kens: Right, but that's 2 different invocations of the pattern. | 11:54.27 |
| kens | Robin_Watts : Yes, but I wasn't sure how you were talking about storing a pointer to the parent gstate | 11:54.51 |
| | If you regard these as 2 different patterns (even if they are the same PDF object) then tha'ts fine | 11:55.07 |
| Robin_Watts | kens: Not within the pdf object itself. Within the derived "material" structure. | 11:55.17 |
| | kens: Yeah, I think we'll be fine. | 11:55.24 |
| | This is specifically tested within your pattern torture test file. | 11:55.34 |
| kens | I thought it was yes | 11:55.44 |
| | Like I said, we had some ugliness with this in my former employment | 11:56.02 |
| | Both Jaws and Harlequin had to gain some nasty hackery to get patterns to work 'properly' | 11:56.20 |
| Robin_Watts | yeah. At least I have a vague clue of what to try now. | 11:56.25 |
| | and there is at least the possibility that this might still fall out nicely. | 11:56.37 |
| kens | As far as I can tell, everyone who deals with patterns in PDF goes 'what were they *thinking* of'..... | 11:56.57 |
| Robin_Watts | On the lcms mailing list, Marti says "Sorry, I am try to recovering from a very destructive merge that has inserted lots of tabs ruining the source formatting." | 12:01.03 |
| | If there has been source formatting in lcms I've never seen it :) 8 spaces! 4 spaces! outdent! indent! | 12:01.39 |
| | I wondered if the indentation was actually steganography at one point. | 12:02.08 |
| tor8 | Robin_Watts: maybe the destructive merge was actually a patch that actually indented the source properly ;) | 12:13.31 |
| Robin_Watts | tor8: I was worried that it might have been my patches that he was referring to, but it's not clear to me. | 12:14.03 |
| tor8 | we use tabs in mupdf, so your editor settings may have had that result | 12:14.31 |
| Robin_Watts | but the patches came from gs. | 12:14.46 |
| tor8 | then it makes no sense | 12:14.59 |
| Robin_Watts | hopefully :) | 12:15.11 |
| tor8 | I know you sometimes put very destructive patches in mupdf where you add too many spaces :) | 12:15.28 |
| Robin_Watts | and yet, not enough blank lines :) | 12:16.23 |
| tor8 | exactly! :) | 12:16.36 |
| henrys | mvrhel_laptop: great look forward to the 8 app so I can run it. I guess I probably should get an RT device but I have so many tablets now... | 17:33.25 |
| mvrhel_laptop | henrys: do you have windows 8 now? | 17:33.46 |
| henrys | mvrhel_laptop: not yet but that's easy | 17:34.02 |
| | I can run it in a vm | 17:34.11 |
| mvrhel_laptop | ok. because you can run it in windows 8 as a tile app but not as a desktop app | 17:34.47 |
| henrys | mvrhel_laptop: is the simulator good? | 17:35.01 |
| mvrhel_laptop | of course you dont have the nice touch screen experience, but yes you can use the simulator | 17:35.14 |
| henrys | mvrhel_laptop: right | 17:35.57 |
| | mvrhel_laptop: they are customer 385 I recommend you pass the information to marcosw and let him handle it, unless you think it is something he can't convey effectively. | 17:57.38 |
| mvrhel_laptop | henrys: ok I will do that | 18:17.53 |
| | that is pass it to marcosw | 18:18.07 |
| vtorri | if i (statically) link a lib with mupf, may I use GPL v3 as licence for my lib (and not AGPL v3) ? | 18:37.26 |
| | i have read on wikipedia that there is a form of mutual compatibility for the 2 licenses (section 13) | 18:38.22 |
| Robin_Watts | vtorri: I am unsure. | 18:55.59 |
| | My initial instinct would be to say no. | 18:56.14 |
| | The AGPL is more restrictive than the GPL, hence by linking your code in we can't lose those restrictions. | 18:57.15 |
| | It is possible that you may be able to have your section GPL and ours AGPL though. | 18:57.34 |
| | I am not a lawyer though. | 18:57.43 |
| vtorri | ha | 19:02.06 |
| | maybe | 19:02.09 |
| | my code a GPL, and the mupdf code (which is in a sub dir as AGPL | 19:02.26 |
| | Robin_Watts, answer from a guy in #gnu : | 19:07.20 |
| | the GPL parts stay GPL, the AGPL parts stay AGPL | 19:08.03 |
| | it seems that it is section 13 | 19:14.15 |
| mvrhel_laptop | ghostscript portion of talk written (heavily leveraging last years talk....) now on to mupdf | 23:46.12 |
| | nothing like waiting until the last minute... | 23:46.31 |
| | Forward 1 day (to 2013/05/14)>>> | |
IRC Logs