| | <<<Back 1 day (to 2012/06/05) | 2012/06/06 |
| henrys | perfect view of venus now. | 00:52.56 |
| | bbiaw | 00:53.08 |
| mvrhel | Robin_Watts: just now stepping through this thing | 01:00.36 |
| | lots of stuff generated for such a simple file | 01:00.42 |
| | I guess the knockout groups add a bit to the complexity | 01:00.58 |
| | no venus view here | 01:01.37 |
| | rainy and overcast :( | 01:01.43 |
| | Junuary | 01:01.57 |
| | oh | 01:03.27 |
| | I see Robin | 01:03.29 |
| | The last soft mask is composed with a soft mask in the graphic state already | 01:03.50 |
| | so it gets doubled | 01:03.58 |
| | hmm | 01:04.05 |
| | I need to track down why the soft mask is getting recomputed. I do think this *is* the source of our woes | 01:07.11 |
| | or is certainly closely related Robin_Watts | 01:07.23 |
| | obviously it is in the graphic state when the new mask is created | 01:08.13 |
| | if it is going to start a new one the old one should be gone | 01:09.00 |
| | The question is, what in the interpreter code is driving the soft mask getting pushed again | 01:21.56 |
| | sure enough, according to the transparency code push and pops of the extended gstate, it has a soft mask in place when we push the new soft mask group | 01:27.45 |
| | I wonder what happens in the head | 01:27.53 |
| | hmm same thing appears to happen in head as far as the state of the softmask stack is concerned | 01:43.19 |
| | ok at least with the head I can follow the pushes and pops of the trans stack | 01:51.09 |
| | the new one is very confusing | 01:51.21 |
| | Basically the extra groups are creating a bit of noise... | 01:52.16 |
| | aha! | 01:54.05 |
| | It appears that the knockout group that is pushed during the drawing of the smask contents is getting associated with the second drawing of the soft mask | 01:55.01 |
| | that is the softmask is present in the graphic state | 01:55.16 |
| | when this knockout group is pushed | 01:55.33 |
| | so when the pop occurs for the group we apply with the soft mask | 01:55.46 |
| | i.e. the soft mask gets the soft mask applied to it | 01:56.01 |
| | the knockout group really should have the softmask set to NULL | 01:56.45 |
| | so, the double drawing of the softmask is an issue in the interpreter and really should be addressed by alexcher | 01:59.28 |
| | and I can probably help him to track this down | 01:59.41 |
| | but that is separate from the problem that we are seeing, which is that for the knockout group that we add, we really need to set the softmask to NULL and wrap with a gsave grestore like we do with the alpha and blend mode | 02:00.34 |
| | Robin_Watts: we can chat more about this tomorrow. I think though you probably understand what is needed in the interpreter code | 04:12.12 |
| | I am going to see now, why we even end up doing another softmask to begin with | 04:12.39 |
| | that is also an interpreter issue | 04:12.56 |
| | oh | 04:14.13 |
| | I think I see why we have to do this | 04:14.19 |
| | or I suspect | 04:14.46 |
| ray_work | mvrhel: When I was tracking through the pdf14 compositor calls for cust 532 pdf14 optimization, I was seeing two "push smask" and two pops for each SMask as well. | 04:36.17 |
| | Since the result matched the head, and our results for SMask in general are OK, I didn't worry about it. | 04:36.56 |
| | mvrhel: and that is 8.71+++ code base | 04:37.23 |
| mvrhel | ray_work you still there? | 05:57.14 |
| | it is not that we are seeing 2 push and pops for each smask. But with every new transparency group occurrence if there is a soft mask in the graphic state we end up doing a gssmask prior to the group. If we already have the mask rendered, we really do not need to do this again assuming there was not an intermediate changing of the smask. Essentially, when we have a smask state set,... | 06:44.16 |
| | ...and multiple transparency groups drawn with that soft mask, we don't want to rerender the softmask prior to each transparency group. To avoid this we either need to pass some id to the C code about the soft mask or make the interpreter smart enough to know that it already did a push for the current softmask and needs not to do it again unless the graphic state is popped. | 06:44.18 |
| | this is not work for the faint of heart as there are plenty of files that have convoluted transparency groups and masks | 06:45.20 |
| | I think for the time being Robin_Watts simply gets the smask to NULL during the knockout group push | 06:45.37 |
| | and that will solve his problem | 06:45.42 |
| | time for bed... | 06:46.13 |
| chrisl | good night ;-) | 06:46.28 |
| mvrhel | good night | 06:46.32 |
| kens | chrisl ping | 07:06.19 |
| chrisl | kens: pong - I missed your ping last night..... | 07:07.02 |
| kens | NP | 07:07.09 |
| | did you see the mail from Aaaron ? 'foreign language cidfmap...' | 07:07.25 |
| chrisl | Yes, I saw it | 07:07.42 |
| kens | Do you have the installer code to do the generation ? | 07:07.51 |
| | I'm assuming there's no actual magic in it | 07:08.12 |
| chrisl | It just runs a PS file through Ghostscript | 07:08.40 |
| kens | Really ? Does it generate teh PS ? | 07:08.54 |
| chrisl | No, I think it's in lib..... | 07:09.15 |
| kens | How odd, I wonder how it gets the patsh for the fonts.... | 07:09.28 |
| chrisl | The file is lib\mkcidfm.ps | 07:10.08 |
| kens | He, I'd got up to j... | 07:10.26 |
| | Ah,it uses FONTDIR which is set up as part of the installation. | 07:10.48 |
| chrisl | The installer uses (I think) an environment variable to get the path to the windows font directory | 07:11.06 |
| kens | Yep | 07:11.12 |
| | Though it probably interrogates the Registry or some such ugliness | 07:11.29 |
| chrisl | If it does that, it must be handled by the installer, not by us...... | 07:11.56 |
| kens | Possibly true, its the sort of thing installers do | 07:12.16 |
| | Do you want to write a reply or shall I ? | 07:12.52 |
| chrisl | If you look in psi/nsisinst.nsi, line 210, that's the function that handles it in the installer | 07:13.23 |
| kens | OK | 07:13.35 |
| chrisl | If you've got enough information, I'll leave the reply to you - if not, I'll draft something | 07:13.55 |
| kens | I think I have enough now thanks | 07:14.05 |
| | First thing I'll be pointing out is that they need to sort this out themselves | 07:14.19 |
| chrisl | You could also mention that 9.05 has slightly smarter CIDFont substitution for PDF files...... | 07:16.57 |
| kens | Yes, I intend to do that too. | 07:17.08 |
| | THe font directory $FONTS is set up by hte NSIS installer, and that's what we use. | 07:18.23 |
| | $FONTS is a predefined constant in the installer | 07:18.37 |
| chrisl | Yes, so I'm not sure where it gets the value - I can probably find out if needed | 07:19.27 |
| kens | No, I woudn't worry, it undoubtedly queries the OS in some manner | 07:19.47 |
| | Either an API call or a Registry read | 07:20.02 |
| chrisl | Hmm, doesn't say where it comes from (nsis reference): "$FONTS: The system's fonts directory." | 07:23.12 |
| kens | Yes, I read the docs too :) | 07:23.23 |
| | LIke I said, it'll either be a API call, or a Registry read or something similar. There are ways to get this information out of Windows, I just can't recall what they are off-hand | 07:23.54 |
| | THey probably also differ depending which version you are running.... | 07:24.09 |
| | chrisl I'm just sending you a proposed answer to Aaron, would you sanity check it for me please ? | 07:47.07 |
| chrisl | kens: sure | 07:47.51 |
| | kens: two things: I think you are being a little pessimistic about mkcidfm.ps - it has the language compatibilities for the "common" Windows fonts pickled into it, so generally makes a decent job of creating the cidfmap. Second, the CIDFMAP parameter is the full path (*including* file name) to the cidfmap file, not just the directory. Other than that, seems okay to me. | 07:53.45 |
| kens | Well I'd prefer them to do the work themselves, which is why I'm trying to put them off using mkcidfm.ps | 07:54.19 |
| | I don't want to end up having to support it. | 07:54.27 |
| | I'll alter the cidfmap I hadn't norticed I'd just said directory. | 07:55.07 |
| chrisl | Well, in that case, you could say that mkcidfmap is part of *our* install process, and if they use it outside our installer, they do so at their own risk | 07:55.37 |
| kens | OK I'll ad that too. All the better to put them off :) | 07:55.52 |
| chrisl | reboots..... | 08:26.52 |
| kens | Off out for a couple of hours. | 09:24.58 |
| Robin_Watts | mvrhel said "I think for the time being Robin_Watts simply gets the smask to NULL during the knockout group push" | 12:09.46 |
| | But how the hell do I do that? | 12:09.51 |
| chrisl | Robin_Watts: /SMask null def? | 12:19.51 |
| Robin_Watts | no, the softmask is one aspect of the transparency setup in params, not just a postscript value. | 12:20.41 |
| | There is a softmask stack, and so what I need to do is somehow arrange the top element of that stack to be NULL (or it's equivalent) | 12:21.29 |
| chrisl | Yes, but IIRC the transparency params are in a PS dictionary in the PDF interpreter | 12:21.34 |
| Robin_Watts | oh, hmm, do it at that level? maybe... | 12:22.28 |
| chrisl | Otherwise, how can you be sure it's the *right* time to remove the Smask | 12:23.15 |
| Robin_Watts | because I'm changing the PDF interpreter code. | 12:23.50 |
| chrisl | Oh, when you said "at that level" I thought you were trying to work out how to set the SMask to NULL in C | 12:24.46 |
| Robin_Watts | I'm trying to figure out what postscript operators I should call that will cause the the SMask to get set to NULL. | 12:25.50 |
| | I hadn't considered fiddling with the PDF interpreters state itself (and indeed, I'm still not quite sure how changing the SMask in the record would actually get communicated to the C side) | 12:27.00 |
| chrisl | IIRC, .begintransparencygroup takes a dictionary which contains the transparency parameters, I would assume that the SMask object is defined in there | 12:27.18 |
| Robin_Watts | It isn't. | 12:27.34 |
| | The SMasks are done with begintransparencymask, I believe. | 12:27.48 |
| | BUT... I think I have a plan. | 12:27.56 |
| | which is to add a new dictionary element to begintransparencygroup. If set, that element will mean 'reset the SMask within this group'. | 12:28.28 |
| chrisl | That seems redundant, there must already be a way to define the softmask in a group | 12:29.08 |
| Robin_Watts | which I can safely do because the mask_stack is saved/restored by the begintransparencygroup/endtransparencygroup. | 12:29.10 |
| | chrisl: Not that I can see. | 12:29.24 |
| chrisl | So how do we set a softmask at all, if we can't set a softmask....... | 12:30.21 |
| Robin_Watts | we set the softmasks using begintransparencymask and endtransparencymask | 12:31.19 |
| | not begintransparencygroup/endtransparencygroup | 12:31.33 |
| | and we discard them with discardtransparencymask. | 12:31.52 |
| | I'll try it anyway, and mvrhel can call me an idiot when he arrives later :) | 12:32.39 |
| chrisl | I find it slightly confusing: SMasks aren't "inheritable", so a new group shouldn't keep using the SMask object from it's parent group | 12:35.07 |
| Robin_Watts | I find it more than slightly confusing :) | 12:44.22 |
| | Maybe the way its done is that every group inherits the SMask immediately above it, and never passes it on to its children. | 12:45.31 |
| | So SMasks are always defined, then a group defined that uses them. | 12:45.47 |
| | That would explain why we are seeing the SMasks being redefined each time. | 12:46.07 |
| | lunchtime, anyway. | 12:46.17 |
| chrisl | Yeh, but the SMask should only be applied to one group, not the entire stack...... | 12:46.30 |
| Robin_Watts | My new code defines a group *during* the drawing of the SMask. | 13:40.26 |
| | and that group manages to inherit the *previous* SMask. | 13:40.46 |
| chrisl | You mean it defines a new group whilst *creating* an SMask group? | 13:41.42 |
| Robin_Watts | Yes. | 13:41.55 |
| chrisl | Well, it would be perfectly legal for a PDF to do the same thing | 13:42.30 |
| Robin_Watts | Yes. | 13:42.40 |
| | I guess so. | 13:42.49 |
| chrisl | So, the PDF code is actually broken for this case..... | 13:43.06 |
| Robin_Watts | So, it's quite possible that there is something broken in here, yes. | 13:43.25 |
| chrisl | I think I would be tempted to try to create a PDF which uses a subgroup inside an SMask group, and see if we handle it, and if so, how - and if not.......hmmmm | 13:44.44 |
| Robin_Watts | oooh. | 14:27.55 |
| | I've added the .removeSMask dictionary item, and that seems to solve this particular problem at least. | 14:28.31 |
| kens | time ti test the cluster :) | 14:36.25 |
| Robin_Watts | 236 differences in the gs lowres tests, but non in the pdfwrite stuff any more. That's an improvement. | 14:50.31 |
| | oh, I bet pdfwrite is only tested at 300dpi... | 14:50.50 |
| | henrys: Morning. I saw the hpgl-2 commit go in - nice. | 14:51.24 |
| kens | Robin_Watts : pdfwrite isn't really resolution sensiticve, or do you mean the PDF after production form pdfwrite ? | 14:52.55 |
| Robin_Watts | I mean that when the cluster tests pdfwrite, it first runs pdfwrite, then renders the results. And it only does so at 300dpi - so the lowres tests don't include it. | 14:53.33 |
| kens | Right. | 14:53.40 |
| henrys | are you asking why the new path code didn't trigger pdfwrite changes? | 14:54.14 |
| kens | No, Robin's new code. | 14:54.28 |
| Robin_Watts | henrys: No. I'm testing transparency changes with knockout groups etc. | 14:54.37 |
| mvrhel | good morning | 15:26.09 |
| Robin_Watts | Morning. | 15:26.14 |
| mvrhel | So I hope my comment was not too confusing | 15:27.40 |
| | essentially, if a soft mask is present in the graphic state at the time that a transparency group is pushed, the soft mask is applied to the group when it is popped | 15:28.09 |
| Robin_Watts | right. | 15:28.22 |
| mvrhel | when you add in the new knockout group the soft mask is applied for that one and for the standard group | 15:28.29 |
| Robin_Watts | ok. | 15:28.34 |
| mvrhel | in the pdf interpreter you will want to save the extended graphic state | 15:28.49 |
| | set the smask to null | 15:28.53 |
| | and the do you knockout | 15:28.59 |
| | then pop the extended graphic state | 15:29.09 |
| Robin_Watts | OK. that leads to 2 questions. | 15:29.14 |
| | 1) how do I save the extended graphic state 2) how do I set the smask to null | 15:29.31 |
| mvrhel | those are a minor programming detail | 15:29.53 |
| | ;) | 15:29.56 |
| Robin_Watts | As far as I can tell there is no gsave/grestore thing that works on the extended graphic state. | 15:29.57 |
| chrisl | Robin_Watts: /q? | 15:30.06 |
| mvrhel | yes | 15:30.10 |
| Robin_Watts | and there is no way to set the smask to null. | 15:30.14 |
| mvrhel | hold on this is done someplace | 15:30.23 |
| Robin_Watts | q = gsave right? gsave does not save the gs extensions to the state for transparency, AIUI. | 15:30.56 |
| mvrhel | I think it is tied into the soft mask though | 15:31.11 |
| | I did this | 15:31.16 |
| | hold on one minute | 15:31.28 |
| chrisl | I thought q was the PDF "gsave" | 15:31.52 |
| mvrhel | look in pdf_ops.ps | 15:32.05 |
| | at the definition of /q | 15:32.15 |
| | and /Q | 15:32.17 |
| Robin_Watts | I'm looking. | 15:32.18 |
| mvrhel | line 100 | 15:32.20 |
| | and line 106 | 15:32.23 |
| | .pushextendedgstate | 15:32.41 |
| | popextendedgstate | 15:32.45 |
| | these take care of the softmask stack in the transparency code | 15:32.57 |
| | which I added | 15:33.05 |
| Robin_Watts | Right, so there are magic undocumented operators to save/restore. | 15:33.06 |
| mvrhel | no | 15:33.12 |
| | the softmask has to stay in sync with q and Q from the PDF document | 15:33.30 |
| | now, to set the softmask to null | 15:34.11 |
| Robin_Watts | "no" ? | 15:34.27 |
| chrisl | "q" is doing what "q" needs to do in a PDF file | 15:34.51 |
| Robin_Watts | Right. | 15:34.55 |
| chrisl | Which is *more* than just a gsave | 15:35.04 |
| mvrhel | but it used to *not* save the soft mask | 15:35.13 |
| Robin_Watts | But that may not correspond to what I need to do. | 15:35.24 |
| mvrhel | we could create a soft mask, push a state | 15:35.24 |
| | do a new soft mask | 15:35.32 |
| | and then pop the state | 15:35.37 |
| | and we used to loose the soft mask | 15:35.43 |
| | lose | 15:35.46 |
| | //null SMask | 15:36.17 |
| | I get confused in this whole operator thing in the PDF interpreter code | 15:38.38 |
| Robin_Watts | mvrhel: Me too, massively. | 15:38.52 |
| mvrhel | gssmask is where the soft mask is processed | 15:39.07 |
| Robin_Watts | AIUI SMask is an entry in a dictionary somewhere. | 15:40.07 |
| mvrhel | It looks like if something on the stack is /None it should work | 15:40.09 |
| | SMask is an operator | 15:40.22 |
| | in the pdf interpreter | 15:40.28 |
| | it has a value of null or /gsmask | 15:40.38 |
| | gssmask is the operator that takes apart the soft mask dictionary | 15:41.15 |
| Robin_Watts | pdf_draw.ps line 426: /SMask { gssmask } | 15:41.23 |
| mvrhel | and ends up doing the begintransmask | 15:41.25 |
| | yes | 15:41.32 |
| | so my thought was that you could reset SMask to that | 15:41.44 |
| chrisl | Robin_Watts: doesn't /.execgroup do basically what you want? | 15:41.54 |
| mvrhel | after you finish your knockout group | 15:41.55 |
| Robin_Watts | That looks like a definition of a dictionary to me, with SMask as a key, whose value is {gssmask} | 15:42.01 |
| Gigs- | mvrhel: did you see my messages from yesterday | 15:42.54 |
| mvrhel | chrisl: right line 587 newpath //null SMask | 15:42.58 |
| chrisl | mvrhel: and saving all the graphics states and such before hand....... | 15:43.24 |
| mvrhel | right | 15:43.29 |
| chrisl | Robin_Watts: The name SMask evaluates to a procedure which is {gssmask} | 15:43.41 |
| mvrhel | that was what I had thought | 15:43.54 |
| | if we set it to //null then we will end up not doing a softmask | 15:44.12 |
| Robin_Watts | chrisl: Right. And that makes SMask an operator does it? | 15:44.22 |
| chrisl | No, it makes it a procedure | 15:44.34 |
| mvrhel | I thought /SMask { gssmask } says to just do gssmask when I encounter SMask | 15:45.06 |
| Robin_Watts | and //null SMask means "make SMask be null ?" | 15:45.30 |
| mvrhel | and /gssmask is that long convoluted thing | 15:45.33 |
| | it means it does nothing | 15:45.44 |
| | I assume | 15:45.46 |
| chrisl | It's a procedure of length 1 | 15:45.58 |
| | SMask's value, that is...... | 15:46.10 |
| mvrhel | Gigs--: yes I saw your comment | 15:46.34 |
| | I pinged you but it was probably late | 15:46.40 |
| Robin_Watts | I'll be the first to admit that my knowledge of postscripts nuances is far from great, but I'm confused. | 15:46.49 |
| | Bear with me here... | 15:47.05 |
| mvrhel | just use the force and feel your way through it. thats what I do | 15:47.13 |
| | of course when I start poking in the interpreter things explode | 15:47.29 |
| chrisl | Robin_Watts: there are also (infuriatingly!) two definitions of /SMask :-( | 15:47.59 |
| Robin_Watts | When the interpreter meets "SMask" on the stack, it looks it up in the current dictionaries, and replaces SMask on the stack with its value ? | 15:48.05 |
| | which it then proceeds to execute. | 15:48.17 |
| | is that right? | 15:48.20 |
| mvrhel | where chrisl? | 15:48.27 |
| | oh in pdf_ops.ps | 15:48.58 |
| chrisl | If SMask evaluates to an executable object, it will execute it right away, otherwise it will push the value onto the stack | 15:49.05 |
| | mvrhel: yes, sorry - can't type fast enough...... | 15:49.18 |
| Robin_Watts | Ok. So to 'make SMask null', we need to find the dictionary that contains SMask and assign null to it there, right? | 15:50.08 |
| | how does //null SMask do that ? | 15:50.16 |
| mvrhel | thats a good question | 15:51.05 |
| chrisl | No, SMask is a procedure, you don't want to set that to //null | 15:51.06 |
| Robin_Watts | Ah, so //null SMask runs the procedure with null as it's argument ? | 15:52.02 |
| | That makes more sense. | 15:52.08 |
| chrisl | Yes, exactly | 15:52.09 |
| Robin_Watts | So SMask is not "either set to gssmask or null", it's always set to gssmask, and it gets invoked with either null or something else... | 15:52.38 |
| chrisl | That's not clear to me - what I do see is that everywhere I can fine uses the SMask procedure to set the soft mask | 15:54.21 |
| | I really hate having procedures named for entries in the graphics state like this :-( | 15:55.31 |
| mvrhel | Robin_Watts: ray_work may be able to sort through this | 15:56.08 |
| Robin_Watts | In pdf_ops.ps: /SMask { /SoftMask gput } bdef | 15:56.13 |
| chrisl | Yep, I mentioned that above | 15:56.27 |
| Robin_Watts | chrisl: indeed. | 15:56.35 |
| mvrhel | he wrote some of this stuff for soft masks in the intepreter | 15:56.38 |
| chrisl | As I said, I would use /.execgroup as your template | 15:57.02 |
| Robin_Watts | that looks to me like that takes the parameter and puts it into a dictionary with the key '/SoftMask' | 15:57.04 |
| chrisl | Yes, that's correct, it does | 15:57.19 |
| Robin_Watts | so, under that definition of SMask, doing //null SMask won't actually have any immediate effect. | 15:57.37 |
| | (i.e. something else needs to run that takes the SoftMask value out and actually does something with it. | 15:57.57 |
| mvrhel | Some how you need to make a dummy soft mask dictionary | 15:58.01 |
| Robin_Watts | Well, with my current solution, I don't :) | 15:58.17 |
| mvrhel | that is set to /None or something | 15:58.18 |
| | that would be my guess | 15:58.28 |
| | but I recall this being done someplace | 15:58.37 |
| | in the interpreter code | 15:58.43 |
| Robin_Watts | What I've got at the moment, is a new flag to begintransparencygroup .removeSMask | 15:58.51 |
| mvrhel | we don't want to remove it | 15:59.06 |
| | we want to push it | 15:59.16 |
| Robin_Watts | If that's set when you do begintransparencygroup then no use is made of the softmask at all when pushing/popping that group. | 15:59.30 |
| | (yes, it's a bad name) | 15:59.35 |
| | (my intentions for it changed while coding it - we can give it a better name) | 15:59.53 |
| | .ignoreSMask might be better. | 16:00.01 |
| mvrhel | hold on let me look at something | 16:00.33 |
| chrisl | There are a few places that do "//null SMask" in order to set the state to have no SMask | 16:00.49 |
| Robin_Watts | chrisl: I see 2. | 16:02.10 |
| chrisl | Well, 2 is "a few" | 16:02.24 |
| Robin_Watts | .execgroup and graphicsbeginpage | 16:02.51 |
| chrisl | It seems to me that what you're doing is an exact analogue of .execgroup | 16:02.55 |
| Robin_Watts | Possibly. | 16:03.42 |
| mvrhel | I am surprised I did not see this issue with the /B command group push | 16:03.43 |
| Robin_Watts | chrisl: Except there is no begintransparencygroup/endtransparencygroup in execgroup - presumably that must be in the calling code. | 16:04.28 |
| mvrhel | Robin_Watts: yes I think that is the case | 16:04.40 |
| Robin_Watts | mvrhel: What is the case? | 16:04.58 |
| | (sorry) | 16:05.04 |
| mvrhel | "presumably that must be in the calling code." | 16:05.11 |
| Robin_Watts | right. | 16:05.20 |
| mvrhel | ok | 16:06.07 |
| | I think some how we need to get the SMask entry in the group that you are doing set to /None | 16:07.04 |
| | essentially what we want is to push the state | 16:07.37 |
| Robin_Watts | mvrhel: Or we live with my .ignoreSMask change. | 16:07.59 |
| mvrhel | Robin_Watts: how does that work again? | 16:08.12 |
| | you are adding a C operator? | 16:08.36 |
| Robin_Watts | When we do '.begintransparencygroup' we create a dict with 'Isolated' and 'Knockout' in it, right? | 16:08.40 |
| | I have an optional '.ignoreSMask' entry in that dictionary now. | 16:09.01 |
| | If it's there (and it's true), then when the group is popped, the maskbuf stack is completely ignored. | 16:09.20 |
| mvrhel | oh. so this has to propagate through the clist too though | 16:09.23 |
| chrisl | Isn't it a bit crap to one way of doing that when read from the PDF and a completely different method when we create the group internally? | 16:09.50 |
| mvrhel | Robin_Watts: I would prefer not to do it that way | 16:10.23 |
| Robin_Watts | chrisl: Possibly. But performance-wise there is no comparison, I fear. | 16:10.38 |
| chrisl | Robin_Watts: why does this affect performance? | 16:12.05 |
| Robin_Watts | chrisl: The difference is that my group is guaranteed to be a leaf group. | 16:12.16 |
| | chrisl: endless pissing about with the postscript stack, or... passing an extra bool. | 16:12.35 |
| | potentially on every stroke or fill. | 16:12.53 |
| chrisl | It's not endless pissing about, it's borderline trivial | 16:13.19 |
| mvrhel | calling ray | 16:13.23 |
| Robin_Watts | you and I have different definitions of trivial then. | 16:13.53 |
| mvrhel | he says there is a trick and he is going to on in a second | 16:13.59 |
| chrisl | Robin_Watts: http://pastebin.com/PxCuKwiz | 16:16.08 |
| | Well, except without the newpath! | 16:16.08 |
| | http://pastebin.com/pmuhWjy9 - no newpath.... | 16:17.07 |
| Robin_Watts | chrisl: Right. And that involves calling SMask, which involves running a large procedure. Which involves lots of individual postscript operators. | 16:17.20 |
| | My point was execution time, not number of chars in the source. | 16:17.39 |
| chrisl | Robin_Watts: it shouldn't do much at all when the parameter is null | 16:17.58 |
| Robin_Watts | But when the group exits, it will have to do a load somehow to put the smask back, right? | 16:18.32 |
| | (but thank you for the pastebin - that will be very useful for me to try this) | 16:18.49 |
| | actually, maybe not. | 16:19.41 |
| | let me try it. | 16:19.46 |
| mvrhel | gsave //nodict begin | 16:20.06 |
| | /SoftMask //null def | 16:20.08 |
| | end grestore | 16:20.09 |
| | this is what ray says to do | 16:20.17 |
| chrisl | Oh, that looks familiar ;-) | 16:20.30 |
| mvrhel | oops I see chrisl | 16:21.02 |
| | I was chatting with ray about it when you posted that | 16:21.19 |
| | I think you need the /SoftMask ExtGstate entry though | 16:22.06 |
| | but perhaps with the way things are defined it does not matter | 16:22.26 |
| chrisl | Robin_Watts: I believe the SMask object *should* remain attached to the original group, so there shouldn't be any need to recreate/reset it after popping your "special" group | 16:22.32 |
| mvrhel | Robin_Watts: the grestore will set the smask back | 16:23.23 |
| | Gigs: you still here? | 16:24.55 |
| Robin_Watts | the version with //null SMask isn't working. | 16:26.18 |
| | Let me try /SoftMask //null def | 16:26.27 |
| | but I hold less hope for that one. | 16:26.38 |
| chrisl | Robin_Watts: where are you making these changes? | 16:27.01 |
| Robin_Watts | In pdf_ops.ps | 16:27.13 |
| | they are changes to the /S, /f, /f* definitions | 16:27.39 |
| mvrhel | Robin_Watts: not the definition of fsexec. It looks at SoftMask | 16:28.41 |
| | to see if it is //null | 16:28.46 |
| Robin_Watts | Ah! | 16:28.59 |
| chrisl | There should *not* be two procedures, both called SMask - that's BAD! | 16:29.25 |
| Gigs- | mvrhel: hi | 16:30.52 |
| mvrhel | hi Gigs- | 16:31.07 |
| Gigs- | so it looks like compression is on tiffsep now | 16:31.40 |
| | I guess that isn't going to be a problem, but it is quite a bit slower | 16:31.52 |
| Robin_Watts | " /SoftMask //null def" is giving me problems. | 16:31.59 |
| | Gigs-: You can set the compression on or off. | 16:32.07 |
| mvrhel | Gigs-: yes, I think you can easily turn it off. You can also do a change to get the spot names back to be numbers very easily | 16:32.20 |
| Gigs- | code change or command line | 16:32.31 |
| Robin_Watts | I'm getting a typecheck error. | 16:33.44 |
| chrisl | Robin_Watts: this is hideous: one of the SMask procedures calls the gssmask procedure, and the gssmask procedure calls a procedure called SMask :-( | 16:33.49 |
| mvrhel | nice! | 16:33.59 |
| | recursion | 16:34.03 |
| | hehe | 16:34.11 |
| Robin_Watts | recursion: see recursion | 16:34.15 |
| chrisl | I don't think it is - I think the call in gssmask is the {/SoftMask gput} definition - yuck | 16:34.47 |
| Gigs- | mvrhel: comparing just the full color tiffs with bmpcmp showed no differences, however there were ... file differences | 16:34.49 |
| | mvrhel: still investigating but I wound up short about 100 files | 16:35.19 |
| mvrhel | Gigs-: the change to get the spot names to numbers is a code change | 16:35.33 |
| Robin_Watts | chrisl: Can you see why /SoftMask //null def should give me a /typecheck in --run-- ? | 16:35.46 |
| mvrhel | Robin_Watts or chrisl where is the change to turn off compression in tiffsep | 16:35.57 |
| Robin_Watts | -sCompression=none ? | 16:36.10 |
| chrisl | Robin_Watts: I don't know, I'd have to debug the Postsrcipt | 16:36.57 |
| mvrhel | oh very good | 16:36.58 |
| Robin_Watts | should it be //null /SoftMask gput ? | 16:39.43 |
| Gigs- | don't worry about the compression | 16:39.53 |
| | I don't think it will be too much of an issue | 16:40.00 |
| chrisl | Hmm, what does gput do, I wonder...... | 16:40.04 |
| mvrhel | Gigs-: ok hold on, I am having trouble finding the change for the names.... | 16:40.22 |
| | I know it is a small change | 16:40.28 |
| Robin_Watts | ooh. /doimagesmask has some very familiar looking code in it :) | 16:40.48 |
| chrisl | Robin_Watts: gput does some funny stuff with the dictionary stack - it *might* be specifically to set the value in the dictionary representing the PDF gstate, so it might be you should do it that way...... | 16:42.35 |
| Robin_Watts | //null /SoftMask gput doesn't crash. But it gives the same (still broken) output as //null /SMask. | 16:42.46 |
| chrisl | Is the SMask not being overridden? | 16:43.40 |
| Robin_Watts | That will require me to dig through the debugger. Just a mo. | 16:44.11 |
| chrisl | Could it be because I used Compatible rather than Normal for the blend mode? | 16:44.38 |
| mvrhel | Gigs-: so in gdevtsep.c the call to create_separation_file_name needs to have its last input parameter set to false | 16:46.54 |
| | in tiffsep_print_page | 16:47.14 |
| Gigs- | mvrhel: thanks, I am going to run the corpus again after changing that... it would be a hassle to bmpcmp with the files named differently | 16:47.28 |
| mvrhel | certainly | 16:47.39 |
| Gigs- | besides something weird happened with some of the files and I don't know if it was something I did or not | 16:47.55 |
| mvrhel | Gigs-: thank you for doing this testing | 16:48.13 |
| Gigs- | I was missing about 100 files from the "new" output and I don't know if I made a mistake and deleted them | 16:48.17 |
| | so I'll rerun and see | 16:48.25 |
| | the initial results just comparing the full colors did well, with -t5 there were no differences | 16:48.47 |
| | 725 file corpus or so | 16:48.57 |
| | that was using imagemagick to convert the tiffs to png | 16:50.16 |
| | should be a 1:1 conversion there | 16:50.22 |
| Robin_Watts | chrisl: At the point at which the group is popped, it still has the old smask pointer. | 16:51.16 |
| | so it doesn't look like it's being overridden to me. | 16:51.27 |
| chrisl | Robin_Watts: that's confusing - there's enough code dotted around which does pretty much what you're doing, and we'd get wrong output if they didn't work....... | 16:53.35 |
| Robin_Watts | fsexec does: "SoftMask //null ne" | 16:54.52 |
| | What are the rules with leading /'s ? | 16:55.05 |
| chrisl | The double "//" means immediately evaluate | 16:56.02 |
| | So the name gets evaluated when the procedure is being defined and *not* when it is being run | 16:56.38 |
| | Robin_Watts: there *must* be a way to "unset" a softmask when pushing a new group, otherwise we'd be rendering quite a few files wrongly....... | 17:01.20 |
| Robin_Watts | I've put the following at the start of fsexec | 17:01.48 |
| | SoftMask 80 string cvs print flush | 17:01.56 |
| | so I should expect to see --nostringval-- if there is a dict there, and 'null' if there is null, right? | 17:02.19 |
| chrisl | Yes | 17:02.43 |
| Robin_Watts | I am resolutely seeing --nostringval-- | 17:03.32 |
| chrisl | okay, try SoftMask {exch == ==} forall flush | 17:04.00 |
| Robin_Watts | at the start of fsexec? | 17:04.19 |
| chrisl | Yes, same place as you put your print code | 17:04.46 |
| Robin_Watts | typecheck error. | 17:05.36 |
| chrisl | So, it's not a dictionary, then...... | 17:05.49 |
| | Robin_Watts: argh, sorry, null does give a nostringval - that's different to jaws | 17:06.33 |
| Robin_Watts | actually, I see: null\n14\nError /typecheck in --run-- | 17:06.35 |
| chrisl | Robin_Watts: this is better: SoftMask type == flush | 17:07.25 |
| Robin_Watts | Ah, cunning. | 17:08.16 |
| chrisl | FWIW, the == operator is much more liberal than cvs when converting for printing | 17:08.51 |
| Robin_Watts | nulltype | 17:09.05 |
| chrisl | Okay, so that's working as we expect....... | 17:09.21 |
| | Robin_Watts: so the question is, how does that get communicated from the PS world into the C world? | 17:09.59 |
| Robin_Watts | fsexec is supposed to call .begintransparencygroup | 17:10.25 |
| | but I have breakpoints on that, so I don't believe it's ever been called. | 17:11.34 |
| | So SoftMask must always be null there. | 17:11.47 |
| chrisl | Oh, but your new code does that anyway in each marking op, doesn't it? | 17:12.04 |
| Robin_Watts | And yet the maskstack within the C still manages to pick up something on the stack. | 17:12.24 |
| | Yes, I see *my* calls to .begintransparencygroup | 17:12.36 |
| | but I never see fsexec putting in an Isolated group for me. | 17:12.53 |
| | and fsexec is supposed to put in an isolated group whenever the SoftMask is non null. | 17:13.21 |
| | So therefore SoftMask can never be non null. Let me test for the value of SoftMask before I set it. | 17:13.58 |
| chrisl | Is this *creating* a softmask group, or drawing *through* a softmask group? | 17:14.22 |
| Robin_Watts | Ok SMask is always null even without any of my setting it to null. | 17:17.05 |
| | SoftMask, sorry. | 17:17.10 |
| | The point at which I see the problem is when I am rendering a softmask group. | 17:17.36 |
| chrisl | So it's creating the softmask? | 17:18.10 |
| Robin_Watts | Yes. | 17:18.23 |
| | In the old code I see: btm, fill, etm, (to make the mask the first time) then btg, fill, etg (to draw a group through the mask). | 17:19.10 |
| | Then: btm, fill, etm (to make the mask again) in preparation for what comes next. | 17:20.07 |
| chrisl | Okay, well, a softmask group can't have itself "in force" when it's being created | 17:20.17 |
| Robin_Watts | In the new code, I see: btm, btg, fill, etg, etm (to make the mask the first time) then btg, btg, fill, etg, etg (to draw it) | 17:21.00 |
| | All that works fine. | 17:21.03 |
| | but then when we come to make the mask again, I see: btm, btg, fill, etg, etm and on the etg, it picks up the previous mask and applies that. | 17:22.06 |
| chrisl | Why do we make the mask again? We really should cache the instantiated mask, and reuse it | 17:22.58 |
| Robin_Watts | Yes, we really should, but we don't. | 17:23.11 |
| | let me find you a reference... | 17:23.20 |
| | .settransparencyparams in pdf_ops.ps line 312 | 17:25.41 |
| | % Set the soft mask by rendering the XObject. Doing this every time | 17:25.51 |
| | % is obviously very inefficient; we'll improve it later. | 17:25.53 |
| mvrhel | chrisl: yes. this is a known issue | 17:26.07 |
| chrisl | Oh, right...... | 17:26.21 |
| mvrhel | As I mentioned last night | 17:26.24 |
| Robin_Watts | mvrhel: So... it seems that in all my tests /SoftMask is never being set to anything other than null. | 17:26.35 |
| | (i.e. me setting it back to null doesn't make any difference). | 17:26.45 |
| | I'm trying to understand why the maskptr that the C has isn't reset before the second rendering of the softmask group. | 17:27.26 |
| mvrhel | you mean during your knockout group? | 17:27.57 |
| Robin_Watts | No. | 17:28.04 |
| mvrhel | is the mask getting used during you knockout group? | 17:28.28 |
| Robin_Watts | Yes. | 17:28.39 |
| | We render the mask once (call this M1). | 17:29.00 |
| | We then render a group (G1) that uses M1. | 17:29.24 |
| | We then render the mask once (call this M2) | 17:29.35 |
| | During the rendering of M2, we do a knockout group before a fill. | 17:29.58 |
| | That knockout group is somehow finding M1 still in force. | 17:30.17 |
| | Once again, I don't feel I explained that well. | 17:30.59 |
| mvrhel | right. I thought your changes to the interpreter would fix that. let me look at the C code for a second | 17:31.04 |
| | so the Group G1 that uses M1 does it have a knockout group around it also? | 17:33.06 |
| Robin_Watts | yes. | 17:33.30 |
| mvrhel | and at that time, we don't have a soft mask pending | 17:33.57 |
| Robin_Watts | Indeed. | 17:34.04 |
| mvrhel | so, when you do you new graphic state in the intrepreter, is pdf14_push_transparency_state getting exectuted? | 17:38.44 |
| | this should come from zpushextendedgstate | 17:39.04 |
| | which occurs with the /q command | 17:39.11 |
| Robin_Watts | I don't know. I haven't got a breakpoint there. | 17:40.05 |
| mvrhel | Robin_Watts: My thinking is that we are not pushing down the softmask in pdf14 softmask stack | 17:40.07 |
| Robin_Watts | give me a mo, and I'll check. | 17:40.11 |
| | http://pastebin.com/YkarxvWH | 17:40.19 |
| | That's a (hopefully) clearer explanation of what's going on. | 17:40.35 |
| chrisl | Robin_Watts: I think mvrhel is onto something there: you probably need to push and pop the trans state after you've made the changes | 17:41.19 |
| mvrhel | My thinking is that the pdf14 device needs to know that the current softmask in the graphic state is no longer set | 17:41.26 |
| | right | 17:41.35 |
| | with .pushextendedgstate and .popextendedgstate | 17:41.50 |
| Robin_Watts | right, but as I've said, I am making no changes to the current softmask in the graphic state | 17:41.55 |
| mvrhel | you are in the interpreter | 17:42.22 |
| | but it needs to be communicated to the pdf14 device | 17:42.30 |
| | which is the keeper of the softmask stack | 17:42.36 |
| Robin_Watts | no, /SoftMask is always null. | 17:42.36 |
| | I never change it from being null. | 17:42.48 |
| chrisl | Robin_Watts: actually, I wonder if the fault is in .execgroup - it makes changes to the transparency state, but doesn't do a "push" | 17:43.04 |
| Robin_Watts | chrisl: Could be . | 17:43.18 |
| | My feeling is that there is a bug in the existing code, and my particular usage pattern is just showing it up. | 17:43.41 |
| mvrhel | instead of gsave | 17:43.49 |
| chrisl | Robin_Watts: I hold my hands up and say some of that code is mine, I can't remember exactly which, though | 17:43.56 |
| mvrhel | I think you want to do /q | 17:43.57 |
| | and /Q instead of grestore | 17:44.42 |
| Robin_Watts | mvrhel: I fear that would just be patching around a problem that's already there. | 17:44.54 |
| mvrhel | so that the pushextendedgstate and popextendedgstate occur | 17:44.59 |
| | so that the softmask stack is updated in the c code | 17:45.10 |
| Robin_Watts | have you read my pastebin? | 17:45.15 |
| mvrhel | otherwise the pdf14 device has no idea | 17:45.21 |
| | I have. | 17:45.45 |
| Robin_Watts | The C code should have been informed that M1 is not in force before the second call to btm. | 17:46.12 |
| mvrhel | how are you doing that? | 17:46.21 |
| Robin_Watts | That's irrespective of anything I do. | 17:46.30 |
| mvrhel | ok I guess I dont understand your issue now | 17:46.45 |
| | I thought the issue is that you are adding a new group | 17:46.53 |
| | and you have a soft mask in force | 17:47.04 |
| | that should not be | 17:47.07 |
| | no different than if alpha was 0.2 | 17:47.15 |
| | and you need it at 1.0 | 17:47.19 |
| | otherwise it is applied twice | 17:47.28 |
| chrisl | Robin_Watts: I have to go - I'll check back later if you have more PS queries | 17:47.44 |
| mvrhel | is this not your issue? | 17:47.50 |
| Robin_Watts | Yes, that's the problem. BUT... the SMask shouldn't be in force when I create my group anyway! | 17:47.57 |
| mvrhel | why | 17:48.03 |
| | it is part of the graphic state | 17:48.11 |
| Robin_Watts | OK, look at the first part of my pastebin. | 17:48.27 |
| | In the old code, we create the smask, then create a group that uses it. | 17:49.05 |
| | Then we create the smask again, and create a group that uses it. | 17:49.14 |
| | yes? | 17:49.29 |
| mvrhel | yes | 17:49.32 |
| Robin_Watts | Right, so when we create the smask again, the original smask should no longer be in force. | 17:49.51 |
| mvrhel | this is due to the lazy way that soft masks are executed | 17:49.53 |
| | right | 17:50.27 |
| | and that seems to be correct in the head | 17:50.40 |
| | I dont see the old softmask getting used when the new one is drawn | 17:50.53 |
| Robin_Watts | now, all I am doing in my new code is adding some extra nested groups. | 17:51.06 |
| mvrhel | you make it sound trivial.... ;) | 17:51.29 |
| Robin_Watts | None of my new groups change the softmask state. | 17:51.32 |
| | so why is the softmask no longer being cleared? | 17:51.48 |
| mvrhel | but there is a difference between creating a softmask and creating a group though | 17:52.03 |
| | you are creating a group | 17:52.10 |
| | and comparing that to creating a new soft mask | 17:52.20 |
| Robin_Watts | I am merely adding new group creations nested within existing softmask/group creations. | 17:52.50 |
| mvrhel | but why would you expect the softmask to magically disappear? | 17:53.04 |
| | when you through a new group? | 17:53.09 |
| | I could add 10 new groups | 17:53.16 |
| | and if the softmask is in force | 17:53.20 |
| | it will apply it to all of them | 17:53.27 |
| | just like alpha | 17:53.32 |
| Robin_Watts | I'm not expecting the softmask to disappear at any point that it wouldn't have disappeared in the old code. | 17:53.45 |
| mvrhel | where you are seeing it disappear in the old code is when we start a new mask | 17:54.07 |
| | that is different than a new group | 17:54.18 |
| Robin_Watts | presumably the old code must have had *something* that caused the softmask to disappear after we'd used the first one, and before we start to create the second copy. | 17:54.47 |
| | I have not changed any of that code - so why isn't that same *something* getting rid of the softmask in the new code ? | 17:55.17 |
| mvrhel | likely the popextendedgstate that I want you to try | 17:55.21 |
| | this will remove the softmask | 17:55.34 |
| Robin_Watts | but why do we need another one? | 17:55.38 |
| mvrhel | in the pdf14 device | 17:55.39 |
| | another what | 17:55.44 |
| Robin_Watts | why do we need another popextendedgstate? | 17:56.06 |
| mvrhel | what I would like you to do is to push first, do you knockout, and then pop | 17:56.31 |
| Robin_Watts | I understand. | 17:56.52 |
| mvrhel | I don't know how else you expect the pdf14 device to know | 17:57.05 |
| | it has to have its soft mask stack in sync | 17:57.23 |
| Robin_Watts | yes, I appreciate that. | 17:57.30 |
| mvrhel | with what you are trying to do with the extended graphic state | 17:57.40 |
| Robin_Watts | but nothing I'm doing should be changing that sync. | 17:57.42 |
| mvrhel | well as far as the pdf14 device is concerned, the softmask is on the top of the stack when you do your group | 17:58.13 |
| | you have not told it otherwise | 17:58.20 |
| Robin_Watts | but... the existing code must have - otherwise the existing code is wrong, surely? | 17:58.47 |
| mvrhel | the only mechanism to tell it so is with pushextendedgstate and popextendedgstate | 17:59.03 |
| Robin_Watts | In the old code, *something* must have told the pdf14 device to remove the first smask off the stack before creating the second one, right? | 17:59.25 |
| mvrhel | ok. let me find that | 17:59.36 |
| | but realize that is in interpreter hell | 17:59.53 |
| | and I don't know how that helps us with what we know to be your issue | 18:00.05 |
| | the execution of softmasks in the interpreter and the set up for it there is confusing | 18:00.37 |
| Robin_Watts | I don't accept that this has to be my issue. In fact, I cannot see how it can possibly be my issue. | 18:00.43 |
| | If I never change the softmask state, how can it be my fault that the softmask state is wrong! | 18:00.59 |
| mvrhel | it is not wrong | 18:01.06 |
| | it is the same as the alpha value | 18:01.16 |
| | are you changing the alpha value? | 18:01.22 |
| | and the blend mode? | 18:01.25 |
| | the same thing applies to the softmask | 18:01.37 |
| | they are all parts of the extended graphic state | 18:01.57 |
| Robin_Watts | Having the first smask in force during the definition of the second smask is wrong. | 18:01.59 |
| mvrhel | yes that would be wrong | 18:02.20 |
| | I dont see that occuring in the head though | 18:02.33 |
| Robin_Watts | by the time my code is called, the smask should already have been removed. | 18:02.44 |
| mvrhel | huh? | 18:02.56 |
| | by what mechanism? | 18:03.26 |
| Robin_Watts | Your argument, AIUI, is that it is something that I am doing (or not doing) within the /f operator that is causing the old smask to have been left on the stack. | 18:03.57 |
| mvrhel | no | 18:04.06 |
| | I am saying that much like CA and ca you need to have the softmask set up properly | 18:04.40 |
| | if you did not set CA and ca you would have issues yes? | 18:05.00 |
| Robin_Watts | I am prepared to believe that in the general case, yes, I will need to be doing something broadly equivalent with the SMasks that I am doing with CA and ca. | 18:05.50 |
| mvrhel | ok | 18:06.05 |
| Robin_Watts | But for this particular example, with the code as it is at the moment, I never touch the softmasks. | 18:06.13 |
| | hence the softmasks should behave exactly as they did in the old code. | 18:06.43 |
| mvrhel | ok I am having trouble following your "particular example" | 18:06.54 |
| | so there are no softmasks in this example? | 18:07.06 |
| Robin_Watts | i.e. they should push and pop onto and off of the softmask stack exactly as they did in the old version. | 18:07.22 |
| | My new groups should have no effect on when they spring into life and when they are removed and destroyed. | 18:07.54 |
| mvrhel | hold on phone with wife | 18:08.05 |
| | ok I feel like I have a moving target here | 18:08.50 |
| | have you changed the original problem | 18:09.05 |
| Robin_Watts | No. | 18:09.11 |
| mvrhel | so AIUI the pdf file sets a graphic state with a softmask | 18:09.35 |
| Robin_Watts | yes. | 18:09.43 |
| mvrhel | a group push occurs that is going to draw a red squre | 18:10.01 |
| Robin_Watts | yes. | 18:10.07 |
| mvrhel | so at that point, you push your new group which is drawn | 18:10.17 |
| | and the main group from the file occurs | 18:10.39 |
| | before which the softmask is rendered? | 18:10.50 |
| | or is the softmask rendered before you knockout group? | 18:11.19 |
| Robin_Watts | Hold on, let me put some labels into my pastebin, so we can talk more easily. | 18:11.23 |
| mvrhel | ok I see | 18:12.29 |
| | so actually the mask is drawn first | 18:12.39 |
| | and then your knockout occurs | 18:12.46 |
| | which does not use the mask | 18:12.52 |
| | and then the source file group occurs | 18:13.03 |
| | which does use the mask | 18:13.07 |
| | then in the second case, | 18:13.14 |
| Robin_Watts | My knockout occurs as *part* of the process of drawing the mask. | 18:13.15 |
| mvrhel | oh | 18:13.31 |
| | gotcha | 18:13.34 |
| | that makes more sense | 18:13.39 |
| Robin_Watts | http://pastebin.com/VAyWFJdi | 18:14.31 |
| | New version with labelled lines. | 18:14.38 |
| | labels are the same in the new and the old code. | 18:15.15 |
| | labels that are in the new code and not the old code pertain to my new knockout groups. | 18:15.43 |
| | Does that make sense? | 18:16.02 |
| mvrhel | yes. it makes sense. and I still think it is the same issue. | 18:16.44 |
| Robin_Watts | OK. | 18:16.49 |
| mvrhel | the first time through in 1-5 the softmask is empty | 18:17.03 |
| Robin_Watts | Yes. | 18:17.14 |
| | Then 6-A has the softmask in force. | 18:17.28 |
| mvrhel | the second time in C-G it is not | 18:17.28 |
| Robin_Watts | then something must happen at around about B in the old code that stops the SMask from being in force. | 18:17.52 |
| mvrhel | No it is still in force | 18:18.10 |
| | but a new soft mask is created | 18:18.18 |
| Robin_Watts | Is it that you are only removing the old smask on an etm ? | 18:18.47 |
| mvrhel | yes | 18:19.03 |
| Robin_Watts | Right. | 18:19.18 |
| | That explains everything. | 18:19.23 |
| | Why? | 18:19.29 |
| mvrhel | hmm hold on | 18:19.37 |
| | that is not true | 18:19.39 |
| | if a pop state occurs | 18:19.52 |
| | it will be removed | 18:19.54 |
| | when etm occurs, the mask is stored | 18:20.33 |
| | and used | 18:20.43 |
| | until we pop it | 18:20.47 |
| | in the manner that I told you | 18:21.00 |
| Robin_Watts | etm pushes the mask. | 18:21.06 |
| mvrhel | zpopextendedgstate | 18:21.11 |
| Robin_Watts | So presumably at B there must be a zpopextendedgstate ? | 18:21.32 |
| mvrhel | zpushextendedgstate will also push a mask | 18:21.38 |
| | it is missing | 18:21.55 |
| | and that is a bug | 18:21.59 |
| | I mentioned that earlier | 18:22.05 |
| Robin_Watts | sorry? | 18:22.18 |
| | Can you run the last 5 or so lines past me again? | 18:22.29 |
| mvrhel | oh sorry | 18:22.35 |
| | I was thinking of \B stroke and fill | 18:22.53 |
| | it will have the same issue as we have here | 18:23.02 |
| Robin_Watts | right, ok. No, I meant in my pastebin. | 18:23.17 |
| mvrhel | in your pastebin... | 18:23.26 |
| | I would suggest you put a breakpoint at zpushextendedgstate and zpopextendedgstate | 18:23.41 |
| Robin_Watts | etm takes the smask that's just been rendered and puts it onto the stack? | 18:24.28 |
| | (does the interpreter do a zpushextendedgstate there? Or is that implicit in the etm?) | 18:24.58 |
| | Then at B (in the pastebin) we must do a zpopextendedgstate to remove the SMask ? | 18:25.28 |
| mvrhel | etm does take the smask that has been rendered and puts it onto the stack | 18:26.27 |
| | if a q occurs then a copy is pushed on the stack iirc | 18:26.54 |
| | if a Q occurs a softmask is popped from the stack | 18:27.09 |
| | question is, when q occurs, how do we make sure that softmask is null | 18:27.45 |
| | can't remember how that works | 18:28.02 |
| | I do remember having some very complicated softmasks with q and Q in some files that drove me batty | 18:28.39 |
| | with softmasks inside of softmasks | 18:28.48 |
| | etc etc | 18:28.53 |
| | but, I *think* what we want to do prior to your knockout group | 18:29.59 |
| | is to do a pushextended gstate | 18:30.15 |
| | get the softmask to be /None | 18:30.29 |
| | do your group | 18:30.34 |
| | end your group | 18:30.40 |
| | do a popextendedgstate | 18:30.54 |
| | it maybe best to have ray_work do this part | 18:31.14 |
| | Robin_Watts: I have to head out to get the kids from school | 18:31.50 |
| Robin_Watts | mvrhel: OK. THanks for the conversation. | 18:32.08 |
| | I still don't believe that adding more pushes and pops will plaster over the existing crack. | 18:32.29 |
| mvrhel | but it is just to get the pdf14 device softmask stack set up | 18:34.08 |
| | otherwise how can it know | 18:34.12 |
| | these commands go through the clist even | 18:34.31 |
| Robin_Watts | mvrhel: All the calls that happen in the old version happen in the new version. | 18:34.35 |
| mvrhel | right | 18:34.44 |
| | but you are also setting ca and CA | 18:34.51 |
| Robin_Watts | None of the new calls affect softmasks (in this example) | 18:35.01 |
| mvrhel | those dont happen in the old version | 18:35.02 |
| | you had to add them | 18:35.14 |
| | to get proper rendering | 18:35.17 |
| Robin_Watts | ca and CA affect the shapeopacity and alphaopacity, right? | 18:35.18 |
| | They don't affect softmasks. | 18:35.25 |
| mvrhel | right | 18:35.29 |
| | but they behave the same as the softmask | 18:35.38 |
| Robin_Watts | So none of my changes should make any odds to the softmask stack. | 18:35.50 |
| mvrhel | you have to communicate the value you want | 18:35.51 |
| Robin_Watts | Yes, for the general case, I will need to do as you say and add the pushes and the pops. | 18:36.09 |
| mvrhel | right | 18:36.16 |
| Robin_Watts | But I do not believe that the lack of those pushes and pops explains the current problem. | 18:36.24 |
| mvrhel | I am feeling like we are talking about 2 different things. Sorry I dont know if I have been much help | 18:36.38 |
| | gtg | 18:36.50 |
| Robin_Watts | mvrhel: Are you around? | 20:23.46 |
| | I'm confused by pdf14_push_transparency_state. | 20:24.49 |
| | If we have a mask in force (ctx->mask_stack != NULL) then make a new mask. Then make the new mask the PREVIOUS one ? | 20:25.28 |
| | And pop does exactly the opposite. | 20:29.02 |
| | i.e. it keeps the new "previous" one, and throws away the "current" one. | 20:29.18 |
| | Something is very wrong here. Possibly with my brain. or reality. | 20:29.40 |
| | (sorry, I was unclear there. Pop does NOT do the opposite of push. Push looks to be doing the wrong thing) | 20:34.02 |
| | mvrhel: ping me when you get back please? | 20:34.41 |
| mvrhel | Robin_Watts: I am back | 21:22.02 |
| | so maybe this is not what you want then | 21:22.13 |
| | now I remember | 21:22.21 |
| | when q occurs | 21:22.25 |
| | we need to push the smask and add the same on to the stack | 21:22.37 |
| | so that if a Q occurs the softmask is still in force | 21:22.52 |
| Robin_Watts | hi | 21:23.35 |
| ghostbot | hey | 21:23.35 |
| mvrhel | need to think a bit more about this | 21:23.35 |
| | hi ghostbot | 21:23.40 |
| ghostbot | hola, mvrhel | 21:23.40 |
| Robin_Watts | mvrhel: Can you look at pdf14_push_transparency_state. Does it look right to you? | 21:24.09 |
| mvrhel | Robin_Watts: I can. It has worked for a long time though... | 21:24.26 |
| | hold on | 21:24.34 |
| Robin_Watts | I'm quite prepared to be wrong, but I just can't wrap my head around what it's doing. | 21:25.07 |
| mvrhel | yes. based on what I said above I think it is correct | 21:25.10 |
| | like I said if I had a condition where I set a soft mask | 21:25.21 |
| | and then do q q q q q | 21:25.26 |
| | I should have multiple copies of the soft mask on the stack | 21:25.35 |
| | as I do Q Q Q Q | 21:25.45 |
| | they start to disappear | 21:25.51 |
| Robin_Watts | Right. | 21:25.55 |
| mvrhel | until finally we get rid of the top one | 21:26.03 |
| Robin_Watts | So when you do a push, we make a new_mask | 21:26.13 |
| mvrhel | yes | 21:26.19 |
| | and it inherits the previous one | 21:26.32 |
| | since it is just a method to keep in sync with q and | 21:26.43 |
| | Q | 21:26.44 |
| | nothing more | 21:26.46 |
| | if there is not a soft mask | 21:26.56 |
| | we do nothing | 21:26.59 |
| Robin_Watts | I would have expected us to do: new_mask->previous = ctx->mask_stack->previous; ctx->mask_stack = new_mask | 21:26.59 |
| | so the new one is on the top of the stack. | 21:27.13 |
| | and the old one is held as the one that we will fall back to on a pop. | 21:27.28 |
| mvrhel | ok. I dont think the stack architecture is the issue | 21:27.56 |
| Robin_Watts | And indeed, when we do a pop, the code throws away the ctx->mask_stack, and goes back to ctx->mask_stack->pvreious | 21:28.00 |
| | BUT... push does not work that way. | 21:28.26 |
| mvrhel | this thing had to be set up to handle some very icky cases | 21:28.29 |
| Robin_Watts | Push makes a new_mask, and adds it as the previous one. | 21:28.50 |
| mvrhel | ok hold on | 21:28.56 |
| Robin_Watts | If you do multiple q's you'll only ever get 2 things on the stack. | 21:29.09 |
| mvrhel | right | 21:29.41 |
| | but we are also reference counting | 21:29.49 |
| Robin_Watts | so? | 21:30.06 |
| | reference counting doesn't magically make up for pushing not doing the right thing. | 21:30.24 |
| mvrhel | ok. | 21:30.30 |
| | please give me a moment | 21:30.38 |
| Robin_Watts | Sure, sorry. | 21:30.42 |
| mvrhel | I can't step in | 21:30.45 |
| | and in two seconds fire off answers for this | 21:30.57 |
| Robin_Watts | I understand, sorry. Take your time. | 21:31.17 |
| mvrhel | Since the new_mask is the same as the previous one, it is not clear to me why pdf14_push_transparency_state is wrong | 21:34.53 |
| | oh hold on | 21:35.25 |
| | Robin_Watts: I agree that pdf14_push_transparency_state looks like it is wrong | 21:40.31 |
| Robin_Watts | cool. | 21:40.39 |
| mvrhel | not sure how in the world it could be working though then | 21:40.58 |
| Robin_Watts | I don't think that new_mask is a copy of the old one - I think it's a blank mask. | 21:41.13 |
| mvrhel | as I know I had several files with smasks and multiple q's and Qs | 21:41.15 |
| Robin_Watts | yeah, it seems odd to me too. | 21:41.36 |
| mvrhel | oh | 21:41.47 |
| | hold on | 21:41.51 |
| | let me check one thing | 21:41.56 |
| Robin_Watts | holding | 21:42.00 |
| mvrhel | Let me create a file to test this | 21:45.05 |
| | Robin_Watts: OK. I think this is wrong the way it is written let me work on fixing this tonight | 21:55.04 |
| Robin_Watts | mvrhel: I have a fix here. | 21:55.12 |
| | I'm just about to clusterpush it. | 21:55.22 |
| mvrhel | ok. that is fine | 21:55.28 |
| Robin_Watts | (I mean, if you want to do it, that's great, but I feel I've taken enough of your time and patience already today) | 21:55.52 |
| mvrhel | get ready for things to explode though.... | 21:55.54 |
| | I hope it works | 21:56.05 |
| | I do need to get working on copy_alpha | 21:56.13 |
| | for devn color | 21:56.17 |
| Robin_Watts | yeah. Thanks for your time. | 21:56.30 |
| mvrhel | next week I am in NY with scott | 21:56.31 |
| Robin_Watts | The talk we had earlier was very useful, even if it didn't seem it at the time. | 21:56.49 |
| mvrhel | did you figure out how to get the smask to null? | 21:56.57 |
| | that was the part that I was not sure of | 21:57.05 |
| Robin_Watts | mvrhel: The smask was never anything other than null. | 21:57.12 |
| | That's what had me so confused. | 21:57.20 |
| mvrhel | that is odd. how does it know to start doing one? | 21:57.34 |
| | as some point something has to be set | 21:57.41 |
| Robin_Watts | yes - but it was never non null at any of the points I stopped it at. | 21:58.05 |
| mvrhel | in the pdf interpreter? | 21:58.17 |
| Robin_Watts | I have breakpoints at btg/etg/btm/etm etc. | 21:59.04 |
| mvrhel | you mean in the c code? | 21:59.13 |
| Robin_Watts | in the C code, yes. | 21:59.17 |
| mvrhel | oh I am talking about in the interpreter | 21:59.32 |
| Robin_Watts | and I had the pdf interpreter set to print out the value of SoftMask | 21:59.33 |
| | and it was always null. | 21:59.42 |
| mvrhel | ok | 21:59.53 |
| Robin_Watts | but don't panic about it. | 22:00.05 |
| mvrhel | certainly after etm the soft mask should be set in the C code | 22:00.14 |
| Robin_Watts | Yes, I can see the C mask_stack changing. | 22:00.43 |
| mvrhel | there is a debug dump for that | 22:00.55 |
| Robin_Watts | Watching that was what lead me to the push/pop wierdness. | 22:01.00 |
| | yeah, I spotted that too. | 22:01.05 |
| mvrhel | gotcha | 22:01.06 |
| Robin_Watts | Pushed. And now I shall run away for a bit :) | 22:04.09 |
| | thanks again. | 22:04.28 |
| mvrhel | you are welcome. I don't think I did much though other than add to confusion | 22:04.47 |
| | and get frustrated a bit. sorry if I got snippy | 22:04.55 |
| | you were asking faster than I can think much less type... | 22:05.16 |
| | and this code is so convoluted.. | 22:05.31 |
| | partly due to my own work | 22:05.41 |
| | I can't hardly remember how it worked | 22:05.52 |
| | hopefully devn stuff is a bit fresher in my head. | 22:06.24 |
| Robin_Watts | mvrhel: So, not many diffs. | 23:35.37 |
| | mvrhel: I propose to commit the patch tomorrow. You can see it at the bottom of: http://ghostscript.com/cgi-bin/clustermonitor.cgi?report=robin | 23:36.36 |
| | so if you want to look it over first, you have time. It's not exactly rocket surgery :) | 23:37.00 |
| | Forward 1 day (to 2012/06/07)>>> | |
IRC Logs