| <<<Back 1 day (to 2014/09/07) | 2014/09/08 |
Robin_Watts | tor8: New commits on robin/master | 09:49.16 |
| tor8, paulgardiner: New ReaderView.java commit too. | 10:30.42 |
paulgardiner | Robin_Watts: LGTM. Maybe the commit message has gotten cut off or something | 11:16.34 |
Robin_Watts | paulgardiner: oops. Bad editing on my part. | 11:22.09 |
paulgardiner | The important bits look fine. Worked out rather nicely | 11:22.53 |
Robin_Watts | yeah. | 11:23.04 |
| I've pushed that one. That leaves 2 commits for tor8 to look at on robin/master. | 11:24.01 |
tor8 | piecemeal LGTM | 11:35.33 |
| not convinced of the usefulness of the abort error code | 11:35.52 |
| right, you need to jump across the pdf_processor abstraction callback layer | 11:47.38 |
Robin_Watts | The abort error code saves us lots of time. | 11:58.57 |
| and yes, the alternative would be to pass an 'abort' flag back through all the pdf_processor functions. | 11:59.17 |
tor8 | I'm not fond of how this affects the top level call though, the check for an abort error in mudraw.c | 11:59.39 |
| we're also getting a lot of "warning: Ignoring error during interpretation" messages | 12:00.03 |
Robin_Watts | tor8: We shouldn't be getting those warnings. | 12:00.25 |
tor8 | well, we are... | 12:01.58 |
Robin_Watts | The change in source/fitz/error.c was intended to stop that. | 12:02.19 |
| I am not seeing warnings under windows. | 12:02.28 |
| I wonder what I did wrong. | 12:02.33 |
tor8 | we're inhibiting the original fz_throw error message | 12:02.48 |
| not the pdf interpreter warning that we've encountered errors and are ignoring them | 12:02.59 |
Robin_Watts | Oh, we should probably have the same thing in fz_rethrow. | 12:03.13 |
| I'm using -T -d here to test. Possibly I need to test without the -d. | 12:03.31 |
| We could put the check for abort into all the fz_run_page etc things. | 12:03.48 |
| that way the top level stays clean. | 12:04.00 |
tor8 | oh, I never use -d | 12:04.06 |
Robin_Watts | I use -d cos in this case, it's much faster. | 12:04.15 |
| Aborting without -d doesn't help as much. | 12:04.31 |
tor8 | I think that would be better. swallow it before it percolates up above the fz_run_xxx things | 12:04.32 |
| I was going to ask how this interacts with the cookie and its abort functionality | 12:04.50 |
| why would -d help here? we're not iterating over the page more than once... | 12:05.08 |
Robin_Watts | Currently it does not. | 12:05.11 |
| tor8: Cos the point of aborting is to stop it even having to iterate over the page once. | 12:05.34 |
tor8 | if -d is faster here, I must misunderstand something, or something's gone broke | 12:05.35 |
Robin_Watts | -d means "don't use the list" | 12:05.43 |
tor8 | oh! *disable* use of display list. | 12:05.48 |
| never mind my rambling. yes. as expected! | 12:05.55 |
Robin_Watts | :) | 12:06.05 |
tor8 | mudraw is too complicated! | 12:06.08 |
| so, fix it so that the ABORT exception is swallowed in fz_run_xxx and set the abort cookie so it becomes a two way thing? | 12:07.11 |
Robin_Watts | certainly the first part. | 12:08.01 |
| Need to think about the second. | 12:08.06 |
tor8 | maybe not the latter, the cookie error flag is already set isn't it? | 12:08.17 |
Robin_Watts | In general if the device 'aborts' it should be because the fact it aborted made no difference to what the caller would see. | 12:08.39 |
| I need to fix the warnings though. | 12:08.50 |
tor8 | also, remove the FZ_ABORT enum in the device (it's unused) and please rename FZ_ABORTINTERPRPETETNUEHUNG to FZ_ABORT instead | 12:09.52 |
| I mean FZ_ERROR_ABORT | 12:10.03 |
Robin_Watts | ok. | 12:10.09 |
tor8 | it should also be FZ_TRY_LATER, but that might be too late now :( | 12:10.25 |
Robin_Watts | hi zeniko. | 12:13.45 |
| tor8: zeniko has some patches I believe. | 12:13.59 |
| I think Chrome has changed font recently... | 12:14.51 |
zeniko | Robin_Watts: Hi Robin. | 12:15.29 |
| tor8: There are indeed two small regression fixes on zeniko/mupdf | 12:15.56 |
| which I'd like to get in before the release | 12:16.03 |
| (which I'd assume would be quite soonish) | 12:16.13 |
tor8 | I don't think we've discussed making a release yet, but I guess the time for release is approaching | 12:34.39 |
| Robin_Watts: changed font? | 12:34.58 |
Robin_Watts | Chrome on windows now uses DirectWrite. | 12:35.29 |
tor8 | I read that they'd use a different font API in the chrome browser on windows in the next release | 12:35.31 |
Robin_Watts | yeah, I think that must be it. | 12:35.41 |
tor8 | but I don't use chrome on windows, so I wouldn't know how it's turned out | 12:35.54 |
| does it look better or worse? | 12:36.00 |
Robin_Watts | fonts look thinner. | 12:36.42 |
tor8 | zeniko: your patches LGTM (though I'm not fond of deciphering oddly-ordered comparisons) | 12:36.57 |
Robin_Watts | I suspect it means we get ClearType. | 12:37.03 |
| so kens will hate it. | 12:37.07 |
kens | Correct :-) | 12:37.21 |
| I don't use CHrome much | 12:37.28 |
tor8 | Robin_Watts: slightly different hinting, but more importantly you get kerning | 12:37.29 |
kens | ASctually, I turn off ClearType in my WINdows conmtrol panel, so if Chrome uses DirectWrite, it won't be a problem for me | 12:37.57 |
tor8 | https://www.youtube.com/watch?v=L_W-IXqoxHA (speaking of vision) | 12:38.43 |
zeniko | tor8: I'd have preferred the comparisons the other way as well | 12:39.11 |
| but then most comparisons would have to be doubled | 12:39.36 |
| in order to prevent integer overflows | 12:39.41 |
| tor8: the pdf-crypt patch undoes part of a patch of yours which prevented a buffer overflow | 12:40.15 |
| do you remember whether that part was relevant for the overflow or whether it was indeed just trying to get closer to the spec (which I'd assume from reading the code)? | 12:41.06 |
Robin_Watts | tor8: There is a nice other thing you can do with the blindspot, to show how well your brain fills in. | 12:41.48 |
| rather than having a little cross disappear as he does in that video, draw a vertical line with a gap in it at the point the cross was at. | 12:42.29 |
sebras | Robin_Watts: did you try looking at your blood vessels in you eye? | 12:42.40 |
Robin_Watts | When you get to the right point, your brain fills in the gap. | 12:42.41 |
| sebras: Not yet. | 12:42.50 |
tor8 | Robin_Watts: hm, gotta try that | 12:42.58 |
Robin_Watts | BUT... I have lots of photos of the back of my eye :) | 12:43.06 |
tor8 | Robin_Watts: yeah, that's a pretty neat effect too! | 12:43.45 |
Robin_Watts | http://wss.co.uk/eyes/ | 12:50.13 |
AlexG___ | Hi! MuPDF is advertised as `fast'. Does the statement refer to rendering performance? Is it comparable to or better than AdobeReader's? | 12:51.00 |
Robin_Watts | I think so. | 12:51.16 |
AlexG___ | And a JavaScript interpreter is being implemented as well as support for Annotations. I wonder if one day Widget Annotation based animations could be run inside MuPDF, like the ones produced with the `animate' LaTeX package. | 12:55.02 |
Robin_Watts | AlexG___: That's certainly not on our roadmap. | 12:57.22 |
kens | thinks quesiton 1 is 'can you do that with PDF at all ? ' | 12:57.50 |
Robin_Watts | Maybe with timed transitions between pages? | 12:58.49 |
kens | But those wouldn't be widget annotations | 12:59.08 |
Robin_Watts | true. | 12:59.13 |
kens | I'm assuming this is an animation ohnt the page | 12:59.15 |
chrisl | Probably SWF, I'd think...... | 13:00.33 |
kens | THis seems to be the thing: | 13:01.15 |
| http://pages.uoregon.edu/noeckel/PDFmovie.html | 13:01.15 |
AlexG___ | The animations produced with animate are based on Widget annotations (one per animation frame). They are switched on and off using a JavaScript timer and a the `visibility' property of a Form object (representing the Widget Annot). | 13:01.23 |
chrisl | Hmm, yuck :-( | 13:01.58 |
kens | Well, waht RObin said, I guess | 13:02.01 |
| I'd say if you want an animation, create it in something that animates, then embed the multimedia result as a movie or something | 13:02.31 |
Robin_Watts | AlexG___: It would require some investigation to see how much was missing from MuPDF. | 13:03.47 |
kens | You owuld have to redraw the annotations on the timer, because their visibility would have changed | 13:04.15 |
Robin_Watts | At least, we'd need to change the app so that it could be told "your image of this page is out of date, rerender" | 13:04.18 |
kens | I doubt that MuPDF does that right now | 13:04.22 |
AlexG___ | Yes but that would require other plugins. `animate' just relies on Wodget annotations and some JavaScript (I am the author of that package). The same could also be achieved with OCGs and JavaScript. | 13:04.55 |
kens | AlexG___ : all require the page to be marked as dirty and redrawn (or at least the annotations ot be redrawn) | 13:05.05 |
Robin_Watts | At the moment redraws are all driven by changes in the PDF page rendering happening as a result of input via the app (clicks etc) | 13:05.05 |
| AlexG___: So, if you wanted to look into it, feel free. We'd be happy to answer questions etc. | 13:05.28 |
kens | thinks its an ugly way to do annotations..... | 13:05.34 |
Mario_ | Hello Team, when can I expect Ray to be available regarding: http://bugs.ghostscript.com/show_bug.cgi?id=695459 ? | 13:05.44 |
kens | Or even animations | 13:05.45 |
Robin_Watts | kens: an ugly way to do animations? yes. | 13:05.48 |
| Mario_: Ray will be here in ~3 hours or so. | 13:06.13 |
Mario_ | OK Thanks | 13:06.21 |
kens | Mario_ : Ray is busy on other work. Bugging development engineers about your problems won;'t win you friends | 13:06.22 |
| Unless, of ocurse, you're a commercial customer | 13:06.34 |
| We're nice to people who pay us ;-) | 13:06.42 |
tor8 | kens: That might still not win friends ;) | 13:07.01 |
Robin_Watts | I can't promise that he'll be looking at that particular bug at that point, but I'm sure he'll answer a quick question or two, assuming he's not in a massive rush for a deadline. | 13:07.10 |
kens | True, but at least we answer questions and do the work | 13:07.16 |
Robin_Watts | I believe Mario_ is a prospective customer. | 13:07.32 |
Mario_ | Ken, I'm to. I just need to get money from my client in order pay you :) | 13:07.47 |
kens | Yes, I understand that also, but at the moment, that's a free user bug | 13:07.52 |
Mario_ | *too | 13:07.53 |
chrisl | Ray is almost certainly tied up with a current "high support" customer issue....... | 13:08.06 |
kens | I owuld think so, bug #695471 is probably occupying him pretty much full time for now | 13:08.54 |
| I had a quick peek at it this morning and withdrew in confusion | 13:09.26 |
chrisl | If that's the 532 issue, then yes | 13:09.37 |
kens | Its an SMask with the wrong transfer function (for the following image) | 13:09.59 |
| Becuase the SMask isn't removed when the graphics state sets /SMask /None | 13:10.35 |
chrisl | IIRC, we're support to ignore the transfer function for an SMask image, which may be the problem | 13:10.45 |
kens | Hmm, tha'ts a thought, let me look at that in the PDFRM | 13:11.04 |
| THogvugth Ray seemed pretty sure the SMask was still active after it was unset in the graphcis state | 13:11.33 |
chrisl | kens: in News.html, does the comment about PDF/A-1 and the new colour management code still apply? | 13:12.38 |
kens | Err, possibly, which comment ? | 13:12.51 |
chrisl | "Please note that due to constraints of the PDF/A-1 specification, the new | 13:13.08 |
| color management does not yet apply when producing PDF/A files." | 13:13.08 |
kens | Ah, no that no longer applies, now that we can guarantee V2 ICC profiles, we apply colour management to PDF/A files as well. | 13:13.43 |
kens | is pretty sure that's the case. | 13:14.13 |
chrisl | So, I can list that in the new News.htm.... | 13:14.30 |
kens | Yes, that would make sense | 13:14.42 |
| You probably want to mention the 'outlines for fonts' option | 13:15.45 |
chrisl | Yes, I've got that already | 13:15.59 |
kens | OK I'll keep browsing the changes :-) | 13:16.09 |
| Yeah I see my commit to 'ensure we have V2 ICC profiles for PDF/A-1 and PDF < 1.5' so that old restriciotn is gone. | 13:16.51 |
| Minor feature, pdfwrite now supports Link annotations with GoTo and GoToR actions | 13:19.55 |
| Seems pdfwrite now also supports BMC/BDC/EMC pdfmarks | 13:22.48 |
| And revision 6 security handler. | 13:23.36 |
| THat seems to be everything from my POV | 13:24.17 |
chrisl | the security handler is consuming, not creating..... | 13:24.40 |
kens | Yes, that was what I meant | 13:24.50 |
| PDF interpreter that one, not pdfwrtite | 13:24.58 |
Robin_Watts | tor8: revised patch on robin/master | 14:15.06 |
| Morning fredross-perry | 14:33.19 |
fredross-perry | morning! | 14:33.28 |
henrys | Hi fredross-perry did we ever get you github stuff changed to a branch? | 14:41.03 |
| fredross-perry: I think tor8 wanted to talk to you about that. | 14:41.31 |
fredross-perry | Not yet, thanks. | 14:42.06 |
Robin_Watts | fredross-perry: Effectively the problem is that you created a brand new repo and commited our stuff into it. | 14:42.27 |
| We'd really like you to clone our repo, then to work on a branch. | 14:42.40 |
fredross-perry | Thatâs right, but I can easily start over with an official branch, that would be good. Then I can ditch my repo. | 14:43.16 |
Robin_Watts | If you want, we can take the commits from your existing repo and put them onto a repo formatted as we'd like. Or you can do it. | 14:43.35 |
fredross-perry | do I need an official user area or something? | 14:43.40 |
Robin_Watts | fredross-perry: It can stay on github, that's fine. | 14:43.50 |
fredross-perry | I can do it, I just need some instruction. | 14:43.56 |
tor8 | it just needs to share history with our repo, so we can pull/push across the repos | 14:44.12 |
Robin_Watts | leaves this to tor8. | 14:44.24 |
fredross-perry | OK. thanks. | 14:44.36 |
tor8 | the easiest would be to pull the changes across using format-patch. if you want I can set up a branch and then you can clone that into your github. | 14:44.58 |
fredross-perry | yes, thatâd be swell. | 14:45.18 |
| @tor8, did you get me email a while back regarding CBZ? | 14:46.09 |
tor8 | fredross-perry: yes. we've fixed that, I believe. | 14:46.49 |
fredross-perry | ok great thanks. | 14:46.58 |
| Is there a written guide regarding how Artifex uses git? procedures and what-not? | 14:48.11 |
henrys | is marcos about today, he has a runaway process on my macpro. I sent him email but if anyone knows he's not going to be around for a while I'll kill off the program myself. Thanks | 14:49.45 |
chrisl | henrys: what's the process? | 14:51.34 |
tor8 | fredross-perry: not sure if we have it written down... robin would know better. | 14:52.20 |
fredross-perry | ok | 14:52.29 |
henrys | a group of grep's sendmail and perl that have been running forever | 14:52.30 |
tor8 | but for mupdf, we all have our local repos. we host ours on casper, but it doesn't really matter where they live. | 14:52.42 |
| and we all have each other's local repos added as remotes | 14:52.53 |
| so a "git remote update" will fetch everybody's changes and branches | 14:53.12 |
| then we can review code back and forth, and once a commit is approved it gets pushed to the gold master repo | 14:53.31 |
chrisl | henrys: so not obviously pointless..... I'd just kill them. | 14:53.52 |
tor8 | when setting up a new mupdf git repo, after cloning it, run the "scripts/gitsetup.sh" script to set some default configuration values | 14:54.31 |
| and git hooks | 14:54.41 |
| fredross-perry: so, in your local repository where you've done work so far, you have your remote "origin" set to github right? | 14:56.21 |
henrys | chrisl: hmm what's ddclient? | 14:56.41 |
fredross-perry | yes thatâs right. | 14:56.46 |
henrys | that seems to be the parent of the entire mess | 14:56.58 |
chrisl | I think it's something to do with DNS.... | 14:57.17 |
tor8 | fredross-perry: okay, now you can add mine, robin's and the golden master repo | 14:57.20 |
| git remote add tor git://git.ghostscript.com/user/tor/mupdf.git | 14:57.38 |
chrisl | henrys: http://sourceforge.net/p/ddclient/wiki/Home/ | 14:57.40 |
tor8 | git remote add robin git://git.ghostscript.com/user/robin/mupdf.git | 14:57.46 |
henrys | chrisl: yea I just looked it up | 14:57.50 |
tor8 | git remote add gold git://git.ghostscript.com/mupdf.git | 14:57.58 |
chrisl | henrys: is it using up a lot of resource, or is it just taking an age to complete? | 14:58.28 |
fredross-perry | thanks | 14:58.39 |
henrys | chrisl: both | 14:58.42 |
tor8 | then run "git remote update" to pull down those to your local machine | 14:58.48 |
| let me know when that's done :) | 14:58.55 |
chrisl | henrys: memory or cpu? You change the nice level | 14:59.08 |
| You could..... | 14:59.15 |
fredross-perry | ok. not today âcause I am traveling, but tomorrow for sure. | 14:59.22 |
tor8 | fredross-perry: right. it'll be about 50Mb of download for the first one | 14:59.38 |
| then you can find a branch on my repo, which you can switch to | 14:59.59 |
| "git reset --hard tor/qt" | 15:00.13 |
| but be careful if you've got any changes in your repo, that will wipe them out | 15:00.31 |
| but I've put the files you've got committed on your current github repo in that branch | 15:00.49 |
| then you can force push that to github (git push -f github master) and you should be ready to go | 15:01.14 |
henrys | chrisl: no I think it needs to die ;-) perl has spawned 5 greps each using 50% of a cpu, sounds like it's gone amok | 15:01.31 |
chrisl | Yeh, that sounds bad - kill it, kill it now!! | 15:02.02 |
henrys | chrisl: ugh he's got it cron'd | 15:02.43 |
chrisl | henrys: that's kind of required for dynamic DNS updaters! | 15:03.15 |
henrys | chrisl: whack a mole | 15:14.29 |
chrisl | henrys: how often is it running? I wouldn't have though DDNS updates would run more than every hour or so | 15:15.19 |
Robin_Watts | henrys: Does it go back into the infinite grep thing when it respawns? | 15:16.02 |
henrys | Robin_Watts: I don't think it was respawning there were just several running ... | 15:21.12 |
Robin_Watts | henrys: The cron job runs it once every so often, right? | 15:23.23 |
| So presumably it's expected to run and then die. | 15:23.32 |
henrys | and now there is a sendmail process using 1/2 a cpu. | 15:24.18 |
Robin_Watts | If it runs, and gets stuck in the infinite grep eating CPU, then each time it gets rerun by cron we'll have more and more of them. | 15:24.21 |
| So the question is, when cron runs it, does it get stuck again? | 15:24.41 |
henrys | the question is why is this running on my machine at all ;-) | 15:25.03 |
Robin_Watts | oh, this is on your machine? | 15:25.21 |
| presumably because you don't have static ip? | 15:25.29 |
chrisl | Presumably yours is one of the machines covered by marcos's ddns setup...... | 15:25.40 |
henrys | particularly I don't want sendmail running the security hell that it is. | 15:26.01 |
chrisl | sendmail may be required by the ddns tools to send out status updates | 15:27.03 |
| Although, I would expect to be able to configure it to use a "normal" smtp server instead | 15:27.44 |
| henrys: I think I would be tempted to txt marcosw - this sounds like it needs his input to resolve properly | 15:28.46 |
| Have to head off..... | 15:29.51 |
mvrhel_laptop | Robin_Watts: I am going to get the win_desktop branch merged in today. I may have a question for you when I do this | 17:49.07 |
rayjj | mvrhel_laptop: I'm looking at a bug with SMask in gs. It looks like there is no way to reset the current group to /SMask /None (.endtransparencymask expects that we've been collecting a mask and we need to put it in as the current mask) | 18:04.30 |
| I've looked at various hackish ways to overload the current endtransparencymask, but I'm coming around to needing a new pdf14 compositor operation :-( | 18:05.48 |
mvrhel_laptop | rayjj: I don't quite understand when you would be doing a .endtransparencymask if you did not do a .begintransarencymask. sounds like a PS interpreter issue | 18:06.00 |
| ick | 18:06.10 |
| unless this is some sort of recovery process | 18:06.47 |
rayjj | mvrhel_laptop: no, the problem is that a PDF sets an SMask to something, draws something, then sets /SMask /None | 18:06.48 |
| setting the SMask using 'gs' | 18:07.07 |
mvrhel_laptop | so, the smask that was drawn is just gone? there was no state save? | 18:08.08 |
rayjj | we started the group without an SMask, a 'gs' sets one in place, but the "<< /SMask /None >> gs" doesn't remove it (pdf_draw gssmask just sets it in the PDF interp state, but there are no compositor actions that occur) | 18:08.43 |
| the problem is that the SMask that was used for drawing is inherited by subsequent drawing after the PDF sets it so /None | 18:09.39 |
mvrhel_laptop | so walk me through what the soft mask stack should be in this case. I am not quite following the graphic state saves | 18:10.09 |
rayjj | mvrhel_laptop: we want the SMask for the first drawing operation to go away | 18:10.11 |
mvrhel_laptop | or do you just want a blank one on the stack? | 18:10.27 |
| It is not clear to me rayj | 18:10.36 |
rayjj | mvrhel_laptop: it might be more clear in http://bugs.ghostscript.com/show_bug.cgi?id=695471 | 18:10.48 |
mvrhel_laptop | rayjj: lets be careful though. Is it possible to have a softmask on the stack | 18:11.09 |
| and then it is set to none? | 18:11.23 |
rayjj | mvrhel_laptop: what is needed is for the ctx->mask_stack->rc_mask->data to be NULL | 18:11.28 |
mvrhel_laptop | but then later a restore happens? | 18:11.30 |
rayjj | restore ??? | 18:11.52 |
mvrhel_laptop | Q q? | 18:11.59 |
| the softmask is part of the graphic state. I thought it could be pushed and popped | 18:12.47 |
| if someone set it to none for a particular drawing could you not still have something on the stack? | 18:13.17 |
| or am I missing something rayjj | 18:13.31 |
rayjj | mvrhel_laptop: it can, but the issue here is getting it back. If I do "q << /SMask << actual mask >> >> gs Q" then it goes back the way I want it after "<< /SMask << actual mask >> >> gs ... draw something ... << /SMask /None >> gs" | 18:15.03 |
| the 'saved' element has it's own mask_stack, so that's what the "Q" goes to | 18:15.50 |
| I need to set the ctx->mask_stack to the /None state | 18:17.04 |
mvrhel_laptop | rayjj: right. so basically it needs to be possible to push a /None state onto the mask_stack | 18:18.23 |
| I would think adding something into the structure that indicates that it is a /None mask would be the way to do this | 18:18.56 |
rayjj | mvrhel_laptop: oh, the paramdict ? | 18:19.34 |
mvrhel_laptop | rayjj: I am just trying to imagine all the ways this could go wrong. And with softmasks there seem to be no shortage of ways | 18:21.30 |
rayjj | mvrhel_laptop: yeah :-( The SMask handling in the PDF interpreter is *almost* as bad as the setpagedevice :-/ | 18:22.07 |
| mvrhel_laptop: mostly I just wanted to "vent". I guess i'd have to focus on diddling 'begintransparencymaskgroup' | 18:24.16 |
| passing it a dummy paramdict that conveys "None" | 18:25.29 |
| (of course, pdfwrite and other HL devices have to handle this as well) | 18:25.59 |
mvrhel_laptop | rayjj: that is what I was thinking. does the interpreter send an endgroup for this None mask? | 18:26.44 |
rayjj | henrys: does xpswrite handle writing transparency, or does it just punt to "flatten" | 18:26.46 |
mvrhel_laptop | gosh since xps trans. is so much simplier than pdf, it is going to have to flatten in all but the normal blending case | 18:27.59 |
rayjj | the gssmask section in pdf_draw.ps that detects /None and //null can do anything it wants (begin, end, etc) The problem is that right now it doesn't do ANY compositor actions | 18:28.12 |
mvrhel_laptop | I guess I am still confused then | 18:28.42 |
| if it does no actions then why do you get the endgroup? | 18:29.01 |
rayjj | I'm guessing that xpswrite does the same as PDF 1.3 (flatten the entire page) | 18:29.03 |
| mvrhel_laptop: I don't get endgroup or endtransparencymask or anything. That's why the previous SMask stays in effect past where it is wanted | 18:29.43 |
mvrhel_laptop | oh. I see | 18:30.12 |
| the old group on the stack is getting applied when it should not | 18:30.23 |
rayjj | If I set a "real" SMask, different to the first one, then the first one is properly replaced | 18:30.26 |
mvrhel_laptop | so I would add in the capability onto the stack to have a none value | 18:30.40 |
rayjj | mvrhel_laptop: Thanks for the chat about it. I'll continue to hack at it, and will bounce the "fix" off of you, if you don't mind | 18:31.30 |
| I have to run an errand. bbiaw | 18:31.42 |
mvrhel_laptop | rayjj: glad to talk about it. i dont know if I made it harder or easier.... | 18:31.51 |
rayjj | mvrhel_laptop: the suggestion that steered me to a "dummy begintransparencymask" helped, yes | 18:32.21 |
| mvrhel_laptop: and *anything* SMask related with gs is never easy | 18:32.53 |
| the original file from the customer fails on mupdf (but differently). I suspect mupdf doesn't pay attention to the /TR of the SMask. I'll open a bug for tor later | 18:33.47 |
Robin_Watts | rayjj: For the logs: MuPDF doesn't pay attention to any TR :) | 18:39.20 |
mvrhel_laptop | bbiab | 20:34.52 |
| Forward 1 day (to 2014/09/09)>>> | |