| <<<Back 1 day (to 2013/02/24) | 2013/02/25 |
chrisl | good morning kens | 07:58.48 |
kens | Hi chrisl | 07:58.55 |
chrisl | How were the slopes? | 07:59.06 |
kens | Excellent :-) | 07:59.12 |
| 349 emails to go through now though :-( | 07:59.39 |
chrisl | Really? I thought it had been fairly quiet..... | 07:59.59 |
kens | Well that's what my inbox says. Of course a number of those will be regression emails | 08:00.25 |
chrisl | Oh, right - I automatically filter those | 08:00.48 |
kens | coffee.... | 08:50.53 |
Robin_Watts | I think that bug 693658 should probably be assigned to chrisl/alex/ray/kens rather than me... | 11:22.53 |
kens | Seems reasonable | 11:23.14 |
chrisl | Depends where the crash(es) happen, doesn't it? | 11:23.45 |
kens | Well, I haven't looked at that | 11:24.02 |
kens | is still catching up | 11:24.13 |
Robin_Watts | chrisl: Someone needs to triage them. Marcos has done the first stage of that. | 11:24.42 |
chrisl | Neither have I, given that it was assigned to Robin_Watts, I assumed marcosw had done so based on where the crash is | 11:24.54 |
Robin_Watts | chrisl: That's an umbrella bug. There are potentially hundreds of bugs within it. | 11:25.19 |
chrisl | <shrug> Probably need to check with marcosw why it was assigned to you, then..... | 11:26.32 |
Robin_Watts | cos the support files came in via me, I suspect. | 11:26.50 |
| I have the MuPDF equivalent one assigned to me. | 11:27.12 |
| And the PDF one currently, though that maybe ought to go to alex. | 11:27.27 |
| I can have a go at them all, it's just a question of time. | 11:27.48 |
chrisl | That's true for all of us! You can punt it my way if you want | 11:30.00 |
Robin_Watts | chrisl: If we share them out, it means that 3 of us will need to ignore the bugs rather than 1 :) | 11:31.46 |
chrisl | That was my plan, yes..... | 11:32.12 |
henrys | welcome back kens | 13:57.33 |
kens | Thanks henrys | 13:57.40 |
henrys | Robin_Watts, tor8 (logs), paulgardiner: since you are late anyway do you want to take another week and get the reflow stuff in 1.2 or would that be too ambitious, risky? | 14:03.09 |
| release-wise | 14:03.21 |
| well you aren't late until March | 14:04.10 |
paulgardiner | There's a little tidying that might be worth doing in the app, like greying out icons for features that don't work in reflow mode (e.g., search, text select), but nothing that would take as long as a week. | 14:07.41 |
| Robin_Watts would need to comment on the state of the layout-recognition algoritghm, although looks pretty good to me. | 14:09.08 |
henrys | funny I started thinking about it due to an error I made - I went on about reflow in the 1.2 artifex newsletter (not released so I can fix it) and then I thought it really would be best to have this in 1.2 given the current state of affairs | 14:10.15 |
paulgardiner | The power of the subconcious :-) | 14:15.59 |
Robin_Watts | henrys: I think we should release without it. | 14:17.22 |
| There is no reason we can't do interim releases of the android app. | 14:17.49 |
henrys | sigh | 14:17.49 |
Robin_Watts | but at the moment, it's got some n^2 algorithms in it, and the error handling will leak if it runs out of memory etc. | 14:18.31 |
| Putting it on the critical path for the release seems like a bad idea. | 14:18.59 |
henrys | it just seems much nicer to have "the release" on Google Play one stop shopping ... | 14:19.02 |
| okay I understand | 14:19.11 |
Robin_Watts | releases should be stable. | 14:19.13 |
| google has "release+" :) | 14:19.39 |
henrys | I don't know if the "app" world is as stable as traditional software markets but ... | 14:20.42 |
paulgardiner | Robin_Watts: what about releaeing with an earlier version of the layout recognition algorithm? Ever since you put styles in, we've had something that was well useable | 14:20.47 |
Robin_Watts | henrys: Right, so that's why it seems fine (to me) to do builds for the app store at arbitrary points. | 14:21.32 |
| paulgardiner: It's possible that that is in already, actually. Let me check the git hiustory. | 14:22.11 |
| Ok, so there IS simple reflow in the release. | 14:22.57 |
henrys | tor8:see the logs | 14:23.04 |
| great so we're good | 14:24.29 |
| now if only we had a release ;-) | 14:25.07 |
Robin_Watts | You might want to say that the current release is simple reflow, and more advanced stuff is coming soon. | 14:25.14 |
| tor8: Did you do the rc2? | 14:25.18 |
henrys | Robin_Watts:I will and I am going to reference the press release. Miles will have to coordinate that. Are you ready with that? | 14:26.09 |
Robin_Watts | http://ghostscript.com/~robin/release.txt is done as far as I am concerned. | 14:27.25 |
henrys | very good | 14:28.16 |
Robin_Watts | Today I am looking at valgrind bugs, because html was killing me last week. | 14:40.13 |
tor8 | I don't think we should put the now reflow text structures in the release | 14:40.16 |
| changing the text extraction API this release, just to change it again in the next one because it isn't stable yet is not playing nice | 14:40.47 |
Robin_Watts | tor8: Yeah, all the new structures are out of it at the moment, but the basic reflow mode is there. | 14:40.52 |
| so I think we're good to go. And it means Henry doesn't need to rewrite his newsletter. | 14:41.15 |
tor8 | the basic reflow mode I have no qualms about including. it only affects the android app anyway as well | 14:41.17 |
| right. so I'll build the RC2 today (got distracted on friday) | 14:41.33 |
Robin_Watts | I found that I just couldn't make <div> and <span> based HTML output work properly. | 14:42.19 |
| until I started adding style="display:table-cell" etc. | 14:42.41 |
| and now it's pretty much OK. | 14:42.50 |
| I conferred with some friends who are very knowledgable in this area, and the consensus is that that's the best I'm gonna get. | 14:43.17 |
| unless we want to write javascript to do the layout. And I don't. | 14:43.34 |
tor8 | I suspect you may be trying to preserve too much of the layout... | 14:45.36 |
| and if we want epub output, table (or table-like css) is out | 14:46.03 |
Robin_Watts | tor8: Right. But for html output, I want to keep the structure I've worked hard to extract. | 14:46.51 |
tor8 | I (naively) thought all you'd need was margin settings... or have you started doing columns in the output? | 14:47.47 |
Robin_Watts | columns are needed for things like index pages. | 14:48.07 |
tor8 | right, the spaces between spans | 14:48.37 |
| Robin_Watts: how about the two cases when there are one and two spans per line... do you use plain div and dl/dt/dd lists there | 14:49.41 |
| ? | 14:49.43 |
Robin_Watts | tor8: I do not. | 14:50.14 |
tor8 | I think for more than two columns (not newspaper columns, those should be linearised) having tables is fine | 14:50.50 |
Robin_Watts | <dl><dd><dt> tends to split over several lines. | 14:51.27 |
tor8 | but for plain text and lists (which dl lists can do all forms, since you have the "bullet" as a separate item) I think we wouldn't want to invoke tables | 14:51.28 |
Robin_Watts | i.e rather than: | 14:51.31 |
| *Foo* Bar | 14:51.44 |
| you get: | 14:51.47 |
| *Foo* | 14:51.59 |
| Bar | 14:52.01 |
| I no longer have the bullet as a separate item. | 14:52.25 |
| I spot hanging indents. | 14:52.37 |
| The code to do spotting of list items is currently disabled, as we don't need it to get reasonable results. | 14:53.07 |
tor8 | Robin_Watts: hmm. I've seen dl lists without line breaks. maybe they use float:left styles? | 14:53.20 |
| right, with hanging indents we don't need to worry about actual lists | 14:53.45 |
Robin_Watts | tor8: pass. I suspect it's possible using scary css. | 14:54.02 |
| but as the page gets narrow, floats break down in nasty ways with overlaps etc. | 14:54.16 |
| That's why I ended up going back to display:table-cell | 14:54.28 |
tor8 | right. | 14:54.43 |
henrys | 3 degrees F and a foot of snow a good day to stay home. | 14:54.53 |
Robin_Watts | crumbs. | 14:55.16 |
| It's cold here, but not that cold. | 14:55.25 |
tor8 | that's even colder than here! | 14:55.48 |
henrys | we usually get a few days a year like this but mostly it is nice | 14:57.03 |
tor8 | we've had alternating days of thawing and -10C | 14:57.53 |
| dreadful... always deadly slippery | 14:58.05 |
henrys | wow now the UK has been bumped by Moodys | 15:07.18 |
Robin_Watts | yeah. | 15:10.21 |
| henrys: I'm assuming that paint_path in pxl/pxpaint.c is yours? | 15:15.20 |
| It's possible to get through to the final statement in that function (the gs_moveto) without having ever set cursor. | 15:16.09 |
| hence we get valgrind warnings. | 15:16.14 |
henrys | okay I believe you ;-) | 15:16.40 |
| if you give me a command line I'll fix it. | 15:17.25 |
| or just the test file you are using | 15:17.39 |
Robin_Watts | http://bugs.ghostscript.com/show_bug.cgi?id=693655 | 15:19.03 |
| I almost have a fix. | 15:19.08 |
henrys | oh I reported that, I should have looked more carefully I just assumed it was a library problem. | 15:20.48 |
Robin_Watts | The first one was. The second one isn't. | 15:24.40 |
| hmm. I've modifed the code so that it can never get to the bottom without calling gs_currentpoint. and it's still failing. | 15:27.16 |
| so the current point in the graphics state must be undefined on entry. | 15:27.29 |
chrisl | The gs_moveto() should establish a valid current point | 15:29.08 |
henrys | Feel free to assign that back to me if it is in XL you are working on higher priority business | 15:29.33 |
Robin_Watts | Ah. gs_current_point is reporting gs_error_nocurrentpoint, and we aren't checking the return code. | 15:30.16 |
| Can we ever have a valid path without having a valid point? | 15:32.24 |
kens | I don't see how | 15:32.41 |
Robin_Watts | kens: In PS I'd agree with you. rules might be different in PCL though, depending on how paths are created? | 15:33.15 |
kens | True | 15:33.23 |
chrisl | Does a closepath invalidate the current point? | 15:33.41 |
kens | I thikn it sets it to the initial point | 15:33.54 |
| PS/PDF of course.... | 15:34.27 |
| newpath will begin a path, and have no current point I htink | 15:34.51 |
henrys | if you have no current point likely the move to failed and we didn't check the return | 15:35.23 |
Robin_Watts | Cluster testing a fix now. | 15:39.52 |
henrys | wow pdf browsing in firefox 19 is nice, much better than chrome from what I've looked at so far | 15:42.20 |
| it also has a nice speedup since I last used it, I might switch back. | 15:43.24 |
Robin_Watts | pdf.js, innit. | 15:43.56 |
henrys | right | 15:44.39 |
| chrome hasn't even put out a 64 bit build on mac os x. They don't seem to have a personnel shortage, WTF? | 15:48.04 |
Robin_Watts | henrys: Why would you want a 64 bit build? | 15:48.42 |
| Chrome uses a process per tab model. | 15:48.58 |
| If any one web page needs more than 4Gig, you're doing something wrong :) | 15:49.19 |
henrys | I have several plug ins that depend on it - garmin is one. I don't know why. | 15:51.36 |
Robin_Watts | possibly because the plugin and browser have to follow the same calling conventions (size of pointers etc) | 15:57.02 |
henrys | firefox does seem much more lively to me but it may be because chrome is cookie and crap laden from usage. | 16:04.57 |
chrisl | kens: ping | 16:14.46 |
kens | pong | 16:15.02 |
chrisl | How would you feel about pdfwrite having its own directory in the source tree? | 16:15.22 |
kens | fine by me | 16:15.31 |
| Assuming you will update all the builds :-) | 16:15.45 |
chrisl | So, I'm thinking we'd have "devices/pdfwrite" | 16:16.03 |
kens | Probably ps2write and maybe txtwrite should go in the same place | 16:16.08 |
chrisl | ps2write yeh, not really much option there, I can put txtwrite in there, too. I wasn't sure how much shared code there is, there | 16:17.08 |
kens | FOr txtwrite, not so much, at least at present, but there is some (the Adobe Glyph List for example) | 16:17.31 |
chrisl | There are also some files shared with pswrite, but i wasn't going to bother with that - in the hope it will disappear at some point! | 16:18.17 |
Robin_Watts | chrisl: Maybe a dir for vector output devices? | 16:18.32 |
| pdf/ps/xpswrite | 16:18.41 |
kens | I certainly hope it will go awqay, just as soon as I can get round to a eps2write | 16:18.50 |
henrys | gdevpx, and the tracing device. It would be really nice to do that. | 16:19.21 |
chrisl | Okay, I can do that - "devices/vector" | 16:20.01 |
kens | makes some sense to em | 16:20.14 |
| me* | 16:20.18 |
chrisl | Question then is, would we still want a directory specifically for pdfwrite | 16:20.46 |
kens | ps2write and pdfwrite are so toangled up you can't spearate them | 16:21.05 |
chrisl | When I say "pdfwrite" I mean both pdfwrite and ps2write | 16:21.25 |
kens | Well, I don't know if they need a directory of their own, is this just for neatness sake ? | 16:21.57 |
chrisl | Some logical separation - pdfwrite/ps2write is *by far* the largest device, with the most files associated with it | 16:22.44 |
kens | Up to you, I don't mind either way | 16:23.03 |
chrisl | And what about the PCL and PXL devices? | 16:23.44 |
henrys | anything that is a vector subclass right? | 16:28.23 |
| there are no PCL devices I know of just PXL | 16:28.59 |
chrisl | the trace device isn't a vector device, is it? | 16:29.29 |
henrys | it isn't and if you are going to name in vector and not something like "high level" I'd leave it out. | 16:30.14 |
| I don't know vector seems too developer oriented not user oriented but I don't feel strongly about it. | 16:31.07 |
chrisl | This is where the source files are stored - it is *entirely* developer oriented.... no "user" should even be aware of this! | 16:31.58 |
henrys | Robin_Watts:can you expand upon non file operations in MuPDF - did you mean stream support or url reading? | 16:32.08 |
| I'm looking at your release notes for 1.2 | 16:32.28 |
Robin_Watts | yes. | 16:34.08 |
| and "yes" | 16:34.13 |
| Essentially you can now open a MuPDF document by passing in a stream, rather than a file name. | 16:34.38 |
| We require the stream to be seekable, currently. | 16:34.56 |
| but it means that people can implement their own 'whole-file' DRM systems (one of our customers does that). | 16:35.27 |
| In future it means that we will be able to open files as they download (I have code that shows this working on branch). | 16:36.03 |
| It also means that people can invoke mupdf on files held in memory without having to go to file. | 16:36.40 |
| henrys: Could you review the patch on here please? http://bugs.ghostscript.com/show_bug.cgi?id=693655 | 16:37.57 |
| That's my proposed fix. | 16:38.03 |
| Damn. Wrong file. | 16:38.20 |
henrys | wrong patch | 16:38.36 |
| oh you see it. | 16:38.41 |
Robin_Watts | Right patch there now. | 16:39.36 |
| Hmm. I sanitised the indentation :( | 16:39.44 |
kens | chrisl I fixed that problem with txtwrite, pity the SO user didn't open a bug :-( | 16:47.32 |
chrisl | kens: yeh, he wasn't very helpful, really. I got a weird crash when I tried it, though - it crashed accessing SingleGlyphList | 16:49.22 |
kens | Yes, the code was barking mad wron g | 16:49.39 |
| I must have been having a bad day when I wrote it | 16:49.54 |
| It seems to work more or less OK now, certainly much better | 16:50.19 |
chrisl | I wasn't going to mention it, if the silly sod wouldn't open a bug, then...... | 16:50.50 |
kens | Well it piqued my interest, and teh crash was a Bad Thing | 16:51.07 |
marcosw | henrys: did you see the email from the customer re. the fonts? He does want the 80 fonts from the HP LaserJet set. | 16:54.31 |
henrys | so the answer is ghostpdl/urwfonts, no? | 16:55.58 |
| marcosw ^^ | 16:56.08 |
marcosw | henrys: yes. | 16:58.32 |
henrys | yeah I got one right | 16:58.48 |
| Robin_Watts: sorry distraction reviewing now | 16:59.24 |
Robin_Watts | henrys: np. I'm staring at shading code now, trying to understand what !unlinear means. | 16:59.54 |
henrys | a no whitespace patch would be easier for me. | 17:00.54 |
Robin_Watts | Let me try and make one. | 17:01.02 |
| http://ghostscript.com/~robin/patch.txt | 17:02.24 |
henrys | nice thanks | 17:02.46 |
Robin_Watts | np. | 17:02.52 |
henrys | I should just break down and bring PCL and XL indentation up to speed | 17:03.26 |
Robin_Watts | I tried to maintain indentation, until I got to a point where I found that I was getting confusing results, so I reindented in the hopes that it would make it clear why. | 17:04.17 |
| but it didn't. | 17:04.23 |
| I could reapply the fix to a vanilla file if you want. | 17:04.34 |
henrys | no I'm good | 17:04.42 |
| Robin_Watts: I'm probably missing something gs_currentpoint returns 0 is there is a path. Aside from that the code could be made much clearer with gx_path_is_null() readability wise, that is what you are after, right? | 17:11.59 |
Robin_Watts | henrys: There are 2 separate problems in the file. | 17:12.29 |
| function. | 17:12.31 |
| Firstly, we can get to the final statement without cursor ever having been written. | 17:13.01 |
| and so we can end up setting the current point to an unspecified position. | 17:13.28 |
| I fixed that by adding various gs_currentpoint calls. | 17:13.42 |
| and that lead to the second problem; we were STILL getting undefined values there. | 17:14.10 |
| so I fixed the gs_currentpoint calls to detect whether we had a currentpoint or not. | 17:14.33 |
| If we don't have a currentpoint, then we don't reset the point before we leave. | 17:14.52 |
| So the net effect of this function is that the point doesn't change. | 17:15.09 |
| But I am aware that I may be patching a symptom rather than patching the cause. Hence me asking you to look it over. | 17:15.47 |
henrys | right I'd like to dive into it a little deeper by looking in the debugger. | 17:17.10 |
Robin_Watts | go for it. | 17:17.47 |
kens | OK I think I'm caught up, so I'm heading off. GOodnight all | 17:18.01 |
Robin_Watts | night kens | 17:20.02 |
henrys | Robin_Watts: more thickness on my part, how does the stream stuff help with DRM? | 17:20.47 |
Robin_Watts | henrys: Our customer supplies both reader and content, right? | 17:21.11 |
| They don't use the standard adobe DRM. | 17:21.38 |
| they use their own one. | 17:21.48 |
henrys | got it. thank you | 17:22.04 |
Robin_Watts | So either they need to decode the entire file, and write it to disc unencrypted, for us to then read back in... | 17:22.13 |
| np. | 17:22.21 |
| My PC is messing about. better reboot. | 17:28.39 |
henrys | if anyone is interested: http://ghostscript.com/~henrys/newstake2.txt -- if you critique it a lot I'll take that as volunteering to do it next time ;-) | 17:40.50 |
Robin_Watts | "let's" ? | 17:42.36 |
| Hmm. Professor google says you are right. | 17:43.42 |
henrys | I thought let us | 17:44.07 |
Robin_Watts | yes indeed. | 17:44.15 |
| I personally find that sentence runs on a bit. | 17:44.23 |
henrys | but it is difficult for non english speakers I'll change it. | 17:44.23 |
Robin_Watts | I'd prefer a hyphen before the let's, I think. | 17:44.38 |
| or a semicolon or something. | 17:44.45 |
| "All CMYK device" should be "All CMYK devices" ? | 17:45.24 |
| similarly profile -> profiles in the next sentence. | 17:45.46 |
| treatment -> treatments? (arguable, I guess) | 17:46.16 |
henrys | argh missed that | 17:47.37 |
Robin_Watts | "Further improvements... are include in 9.06". | 17:47.46 |
| I think you need to remove "are included in 9.06" from that sentence. | 17:47.59 |
| "The pdfwrite device now produces output consistent with the linearized PDF specification." <- That's unkind to ken :) | 17:49.10 |
| The pdfwrite device now produces linearized PDFs that work, despite the specification being broken :) | 17:49.45 |
| "MuPDF 1.2 new feature set" => "MuPDF 1.2s new feature set" ? | 17:50.43 |
henrys | Ill wait for other to weigh in and fix everything all at once. | 17:50.44 |
Robin_Watts | Never start a sentence with But (so I was told at school) | 17:51.25 |
| but ( : ) ) other than those small niggles, it looks great. | 17:51.58 |
henrys | actually I didn't really mind writing it ⦠the new stuff in MuPDF is really pretty exciting - Oh god I need a life | 17:53.00 |
chrisl | Just a couple of erroneous mentions of 9.06, that I see - starting a sentence with "But" is like using a "goto" in C.... only do so with care! | 17:53.21 |
henrys | Yeah I don't know if I'll change the but or let's. BUT I might | 17:54.31 |
Robin_Watts | "But for the case of sentences like this, sentences should never start with a but." :) | 17:57.40 |
chrisl | I haven't even had anyone bitching at me about using British spelling in the release notes this time - I must be getting better.... or worse? | 17:59.22 |
henrys | I put mvrhel_laptop on the hook for some kind of window mobile app by 1.3 | 18:04.52 |
mvrhel_laptop | henrys: that should not be a problem | 18:12.05 |
| I have the zooming, scrolling etc working now | 18:12.14 |
| working on adding search this week | 18:12.20 |
Robin_Watts | :points to the "mobile" in that sentence. | 18:12.25 |
henrys | Robin_Watts:I'm hesitant to wave the Affero flag in newsletters, can we drop that part? | 18:12.40 |
mvrhel_laptop | Robin_Watts: yes. the way I am writing things it should work on the surface and the phone | 18:12.46 |
henrys | or press releases | 18:12.51 |
Robin_Watts | henrys: If you'd like it dropped, we can drop it. I felt it deserved a mention though, lest people miss it and then complain that we changed silently. | 18:13.28 |
mvrhel_laptop | that was odd | 18:14.06 |
henrys | well that was my insidious evil plan if you must know - it really is mupdf irrelevant though | 18:14.19 |
Robin_Watts | If our intention is to use it to drive people that might have been using MuPDF or gs on servers to having to come to us for a commercial license, then we need to crack the whip otherwise they won't know we're holding one. | 18:15.02 |
| We get occasional questions on here from people wanting to use mudraw to make pdf thumbnails etc. I reckon that could be a web based thing... | 18:15.55 |
henrys | we generally know who they are in the past we couldn't do anything about it. Anyone with any success is going to get on our radar | 18:15.59 |
Robin_Watts | but yes, less important for mupdf than gs, I will grant you. | 18:16.19 |
| Fair enough. | 18:16.23 |
| I'll happily see it removed. | 18:16.36 |
chrisl | It's not relevant at all for a news letter aimed at our commercial customers | 18:17.47 |
henrys | right or a press release | 18:18.10 |
mvrhel_laptop | need to head out for a bit | 18:20.57 |
ray_laptop | mvrhel_laptop: Robin_Watts: I have partially fixed the SMask issue with bug 693115, so that we get the right yellow, red and green colors including the overlap (comparing to Photoshop CS3), which make sense from the RGB values and the smask alpha values for smask1 | 18:48.26 |
| mvrhel_laptop: Robin_Watts: it also gets rid of the multiple rendering of the SMask that was happening. Now I have to fix the smask2 part (my change is causing it to ignore smask2) | 18:49.31 |
| but it's MUCH better than before, and I didn't have to get rid of the delayed SMask rendering (although I'm not sure if that is ever really of value) | 18:50.26 |
Robin_Watts | Will this cause us to get the sane nesting of renderings ? | 19:24.55 |
ray_laptop | Robin_Watts: sorry, was debugging. I _hope_ so, but that comes after finding out why the blue is painting as opaque. | 19:34.51 |
Robin_Watts | ok. | 19:35.02 |
| My memory of this is superbly rotted now, but I do remember the call sequence as seen from the C side being bonkers. | 19:35.32 |
ray_laptop | Robin_Watts: OK. So what is screwy is that the main Contents stream is not in a group, so it paints the Yellow without an SMask (as it is supposed to), but after (now) properly doing the red and green and blending in them using smask1, it finds the inline rectfill of the blue and it paints that into the top buffer, the same as when it did the yellow. | 19:55.25 |
| this seems legal, but it confuses our transparency code. Our code needs a group (that it can pop) in order to paint the blue with the SMask | 19:57.24 |
Robin_Watts | I *think* mupdf introduces groups at various points to cope with this kind of thing. | 20:09.12 |
ray_laptop | Robin_Watts: probably. So if I change the file to "Do" the blue square following /smask2 gs, then we get EXACTLY the same thing as Photoshop CS3 ! | 20:11.39 |
| (with my changes to fix the SMask stuff) | 20:12.13 |
Robin_Watts | fab. | 20:12.14 |
ray_laptop | so I need to detect the case when a group that didn't used to have an SMask gets one set by and 'gs' operation | 20:13.03 |
Robin_Watts | yeah. | 20:13.38 |
ray_laptop | and push a group for painting, and pop it sometime later | 20:13.40 |
Robin_Watts | "sometime later" = "when the smask is removed from the graphics state" | 20:14.10 |
ray_laptop | and the 'sometime' is at the end of the stream, or when when the SMask changes due to a 'gs' | 20:14.25 |
Robin_Watts | Due to a new gs, or due to a Q or due to the end of the stream. | 20:14.59 |
ray_laptop | need to think about this, but I probably have to hack this into the PDF interpreter | 20:15.12 |
Robin_Watts | (but not the end of ANY stream, the end of the stream in which it was introduced). | 20:15.30 |
ray_laptop | Robin_Watts: oh, right -- a Q might pop the old SMask | 20:15.38 |
Robin_Watts | Probably easiest to do "new gs, or Q", and then arrange to q/Q around streams or something. | 20:15.54 |
| yeah. nesting hell. | 20:16.06 |
| It looked like PDF interpreter hackery was required to me, which is why it ended up getting foisted on alex. | 20:16.25 |
ray_laptop | Robin_Watts: I can (and have) worked on the transparency handling in the PDF interpreter. I did the PS part of many of the bug fixes here (to support mvrhel_laptop) | 20:17.24 |
Robin_Watts | oh, yes, I completely believe you're capable of it. I just know that for me, it would have been a massive undertaking. | 20:18.08 |
ray_laptop | and probably for mvrhel_laptop as well (since it first requires learning PostScript, then deciphering the mess that is the PDF interpreter) | 20:19.10 |
| mvrhel_laptop has done some reading of the PDF interpreter parts, but wasn't confident on making substantial changes, although iirc, he has done a couple | 20:20.12 |
| anyway, time for a lunch break and let this ruminate... | 20:23.13 |
| bbiaw | 20:23.16 |
| Forward 1 day (to 2013/02/26)>>> | |