| | <<<Back 1 day (to 2014/06/18) | 2014/06/19 |
| mattchz | morning | 09:07.40 |
| kens | Morning Matt | 09:07.45 |
| | Robin_Watts : ping | 09:13.47 |
| Robin_Watts | pong | 09:17.10 |
| kens | Looking at a problem with teh bbox device, and I've tracked it back to a commit you made 2 years ago | 09:17.27 |
| | http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=a13600f1c241c3e36dbe4973e9d78a8934b16004 | 09:17.39 |
| | The cause in this case is a glyph which is 'off the page' and sufficiently large to be drawn uncached, which means it gets to the bbox device as an image. | 09:18.18 |
| | Prior to this commit, the clip device would be instgalled and the image would be fully clipped out (its off the page) and so the bbox device would not see it. Now, it does get through to the bbox device, and causes it to create a potentially invalid bbox, as it takes into account the glyphs off the page | 09:19.12 |
| mattchz | I presume these "New muPDF compiler warnings" emails are automatically generated? | 09:19.34 |
| | (badmatt) | 09:19.38 |
| kens | mattchz : yes, they are | 09:19.43 |
| | marcos runs some tools which compare the warnings emitted for a build against the existing warnings and flags new ones | 09:20.12 |
| Robin_Watts | They aren't 100% accurate, so if you see a warning that you think should have been there before, it possibly was. | 09:20.46 |
| kens | Robin_Watts : the odd thing is that the bbox device is checking the clip path and deciding that the image is (at least partially) inside the clip. Or at least, I *think* that's what's ahppening.... | 09:21.15 |
| Robin_Watts | kens: Just trying to figure this out... | 09:21.27 |
| kens | Join the club :-) If you can't recall anythign about this quickly don't worry, I'll keep applying the stick | 09:21.52 |
| Robin_Watts | The code is given the region for the image and a clip path. | 09:22.50 |
| kens | Indeed, and the clip is the page at this point (I believe) | 09:23.08 |
| Robin_Watts | The original code would always create a clip device. | 09:23.16 |
| mattchz | kens> cool. ta. No, I think this one is my fault :) | 09:23.18 |
| kens | Robin_Watts : yes, and if I do that, ths works, because (somewhere along the way) the clip device drops the imagemask | 09:23.46 |
| Robin_Watts | The new code first reduces the image region, and only creates a clip device if there is overlap. | 09:24.00 |
| kens | Correct, and since the glyphs lie well off the page, there is no overlap | 09:24.16 |
| Robin_Watts | Presumably we should adapt the code so that if there *is* no overlap, no plotting of the image is done. | 09:24.35 |
| kens | Well... that owuld be bad for pdfwrite potentially | 09:24.50 |
| | The weird thing is that the bbox device does check the clip path. I think it must be doing it wrong | 09:25.21 |
| | Hmm, OK I think the bbox device is at fault, maybe. | 09:26.25 |
| | gx_cpath_includes_rectangle() returns false, which I would have thought was a good reason to stop. But the code actually calls gx_default_fill_mask() 'Let the target do the drawing, but break the images into pieces for computing the bounding box' | 09:27.34 |
| | I'll guess that teh copy_mono implementation in gdevbbox doesn't check to see if the trapezoid is inside the clip path | 09:28.28 |
| | Yeah looks like the bbox device doesn't check to see if the object is on the page when updating the rectangle | 09:32.50 |
| | Its actually debatable what the correct actionis here I think | 09:35.03 |
| | Should the bbox device include objects which are off the page ? | 09:35.22 |
| | Hmm, OK gx_cpath_includes_rectangle only tells you if a rectangle is *completely* contained in a clip path, it doesn't tell you if its partially contained. I think I need to update the clipping test in gdevbbox so that it jumps out if the rectangle isn't at least partially contained, and decomposes if its partial. | 09:41.06 |
| Robin_Watts | Do we have an email address for ronbo? | 09:49.56 |
| kens | Not that I know of | 09:50.10 |
| chrisl | The web guy? | 09:50.13 |
| | Robin_Watts: ^^ | 09:51.17 |
| Robin_Watts | yeah. | 09:51.24 |
| | chrisl: Thanks. | 09:51.44 |
| chrisl | NP | 09:51.49 |
| Robin_Watts | Hi Shelly_. | 09:57.33 |
| | jogux_mac, pedro_mac: I updated the code so that styles are produced as I would expect, but it's still not working: http://pastebin.com/HZvPXssQ | 09:58.07 |
| | does ordering matter? | 09:58.50 |
| Shelly_ | Hi Robin, long time since I was last here, just chatting with Chris in the other window.... | 09:59.09 |
| jogux_mac | only if there are conflicting rules of the same specificity | 09:59.16 |
| | can you distill the 'doesn't work' down into 'style rule with selector <x> doesn't seem to be applied to edr group=<y>' to save me trying to remember the whole thing again? :) | 10:00.34 |
| Robin_Watts | ah, well, that's trickier. | 10:03.26 |
| | There are 2 pieces of text in the actual Edr. | 10:03.38 |
| | "MSWord (.doc, .docx)" | 10:03.49 |
| | and "Row 2" | 10:03.53 |
| | "Row 2" should be displayed larger than "MSWord" | 10:04.16 |
| | because "Row2" should inherit from NPH TxLevel-3 | 10:04.40 |
| | It's not clear to me if the first row is failing to inherit styles from PH TxBody TxLevel-3 or not, cos the style that is set is pretty much the default. | 10:07.17 |
| | The first row being "MSWord" | 10:07.28 |
| | I am also confused by the "slide316-sp-2" stuff etc, cos I can't see it in more than 1 place. | 10:09.40 |
| Robin_Watts | goes for a run. | 10:11.40 |
| kens | Drat, I wanted to talk to Robin_Watts | 10:13.31 |
| | Can you ping me when you get back please Robin_Watts | 10:13.42 |
| pedro_mac | Robin_Watts: the eDR looks correct to me - Iâd guess thereâs still some funkiness in the selector matching | 10:15.09 |
| jogux_mac | robin_watts: I guess it needs debugging into edr style stuff :( I could delve in if you have other stuff to do. | 10:29.44 |
| pedro_mac | Robin_Watts: possibly worth dumping the selector list in Edr_Style_createSelectorList ? | 10:32.32 |
| pedro_mac | guesses our appstore-ios-good config shouldnât have ENABLE_ONE_CLOUD defined | 10:38.36 |
| jogux | pedro_mac: hm, that looks like a mistake on my part - it doesn't seem to be in the release tracking sheet entry | 10:41.36 |
| pedro_mac | cool - was just looking at the good android release config at the time | 10:43.10 |
| jogux | will you fix that? | 10:44.39 |
| pedro_mac | yeah, Iâve removed it here anyway | 10:45.35 |
| | we should also look at making appstore/playstore apps consistent in terms of language - both have en-gb and ko/cn/jp language support but iOS has hebrew+arabic whilst android has vietnamese and thai | 10:48.24 |
| | perhaps not such an issue for regular appstore builds but may be confusing for Good customers when they do a corporate rollout and have different language support for the same app on different platforms | 10:50.09 |
| jogux | pedro_mac: and the iOS good doesn't match the ios appstore either. | 10:59.06 |
| pedro_mac | mm - maybe we should just add all the existing supported languages, BIDI_TEXT and a decent set of fonts/mappings across all the bulds | 11:00.03 |
| jogux | BIDI_TEXT is history | 11:00.15 |
| | but, yes, I'm tempted to just superset the languages. | 11:00.32 |
| | I don't know if there's any downside to doing so (other than binary size) | 11:00.53 |
| paulgardiner | appstore-ios-so-good differs from the last entry in the tracking sheet in several ways | 11:04.41 |
| jogux | paul: yes. all the other ones are documented in the file or git history though hopefully | 11:05.06 |
| kens | heads off to lunch | 11:18.52 |
| paulgardiner | jogux: Commit message says it's based on build 7935 but it doesn't seem to match and there are no further commits that change that release config | 11:21.09 |
| jogux | paul: there's 2 commits :-) | 11:21.33 |
| | [on master] | 11:21.40 |
| paulgardiner | Hmmm. My git blame seems to be showing a single commit but basing the file on the alteration of another. | 11:23.39 |
| | I may not have fetched on this copy of the repo for a few days | 11:25.11 |
| | jogux: we are talking about appstore-ios-so-good.txt? | 11:30.18 |
| jogux | paul: blame won't show you deleted lines :-) | 11:32.00 |
| paulgardiner | yeah, but I assumed at least ENABLE_ONE_CLOUD had been added as it wasn't in 7935 | 11:33.59 |
| Robin_Watts | misses kens, rats. | 11:34.19 |
| | pedro_mac, jogux: I'll try to have a dig in the selector stuff. I will undoubtably be back later with stupid questions. | 11:34.47 |
| pedro_mac | np - I have many stupid responses at the ready ;) | 11:35.09 |
| rayjj | Robin_Watts: are you talking about the bbox issue ? | 11:36.05 |
| Robin_Watts | rayjj: Yes. | 11:36.26 |
| | See the logs this morning for the dicsussion. | 11:36.52 |
| | The change tracks back to an optimisation I made ages ago, but it looks like it's a problem in the bbox device. | 11:37.13 |
| kens | slinks back | 11:37.34 |
| | I think its more general than just the bbox device, though for rendering it doesn't show up | 11:37.51 |
| | THis may be a 'carboard programmer' discussion, let me wibble for a few minutes | 11:38.20 |
| Robin_Watts | go for it. | 11:38.29 |
| | I'm gently deliquescing after a run :) | 11:38.37 |
| kens | We are deciding whether to install a clip device. The clip device decomposes a masked image into a series of trapezoids. | 11:38.51 |
| | There are 3 condiditions; 1 teh image is wholly within the inner clip rect, and is therefore unclipped. | 11:39.16 |
| paulgardiner | jogux: git log shows 3 commits :-) Shall I update to be what was in the tracking sheet plus the application of the two commits that update the file? That looks to be the intention of what's been done. | 11:39.24 |
| kens | 2 the image is wholly outside the outer clip rect and is therefore totally clipped | 11:39.36 |
| | 3 the image is at least partially within the outer clip region and we can't tell which parts are clipped out | 11:39.59 |
| | We watn to install the clip device for condition 3 only. For condition 1 we just use the 'default' (or target) device | 11:40.35 |
| | For condition 2 we throw the image away | 11:40.45 |
| | There is currently no test for condition 2 | 11:40.57 |
| Robin_Watts | I thought you said that if there was a test for condition 2 that would upset pdfwrite. | 11:41.19 |
| kens | THere is a test for the image rect being degenerate and we throw that away | 11:41.23 |
| Robin_Watts | I'm not sure why though... | 11:41.25 |
| rayjj | kens: no test in the bbox device ? | 11:41.25 |
| kens | Robin_Watts : it doesn't exactly 'upset' pdfwrite, it just means that clipped content will be dropped, turns out we alreayd do that in other cases | 11:41.52 |
| | rayjj yes, but not one that works | 11:42.00 |
| rayjj | kens: other than the bbox device is it OK ? | 11:42.27 |
| kens | The bbox test looks to see if the image is completely *inside* the inner rect, if it is it doesn't bother to render it, if its not, it doesn't | 11:42.38 |
| Robin_Watts | kens: Why is it bad to drop clipped content? Sounds desirable to me. | 11:42.53 |
| kens | rayjj for sufficiently small values of OK, yes, let me continue.... | 11:42.56 |
| | Robin_Watts : what if we change the CropBox on a PDF ? | 11:43.06 |
| | But anyway, we do it anyway, so ignore that for now | 11:43.14 |
| | Now, before Robin's change we would install the clip device, and it would throw away all the stuff outside the clip region, so nothing would get through. | 11:44.01 |
| | Robin's change stops the clip device being installed (this is a good thing, its exepnsive to run) | 11:44.24 |
| | But.... | 11:44.27 |
| rayjj | kens: right, and installing a clip device is a potentially expensive op if there is a quicker solution | 11:44.41 |
| rayjj | types slower than kens | 11:45.12 |
| kens | It means that for totally clipped out content, we end up passing the image to the rendering device. | 11:45.14 |
| rayjj | kens: now you are speaking of the bbox device, or generally ? | 11:45.44 |
| Robin_Watts | So if we completely dropped images in condition 2, we would restore the old behaviour. | 11:45.52 |
| kens | This causes us to degenerate the mask into trpaezoids (expensive) and pass them on. The rendering devices of course throw away the traps outside the page. | 11:46.00 |
| | bbox doesn't | 11:46.13 |
| | SO as it is we end up dfoing a lto of stuff we don't want to, even for the rendering devices, and the bbox device gets stuff that it shouldn't and isn't prepared to cope with | 11:46.42 |
| | Robin_Watts : that was my proposed solution | 11:46.51 |
| Robin_Watts | flinches everytime he sees "SO" :) | 11:46.58 |
| pedro_mac | you love it really ;) | 11:47.16 |
| Robin_Watts | sounds good to me. | 11:47.19 |
| kens | Rather than clamp the rect to the clip (which causes stuff to fall through, I'd prefer to check that the object is clipped out and return NULL, which drops it | 11:47.25 |
| | THe thing is, I'd like to know what proimpted the original change and examine that..... | 11:47.59 |
| rayjj | kens: Robin_Watts: I agree that "if we completely dropped images in condition 2, we would restore the old behaviour" and that would seem to be a good thing (pending regression test) | 11:48.01 |
| kens | It seems like a good thing to me, we won;t install the clip device, but we also won't try and decompose the images into traps, which means we shoudl see even better performance | 11:48.38 |
| | Ooops, I lost the commit, have to check the logs | 11:49.03 |
| rayjj | kens: ahh, I see. You want Robin_Watts to remember what he was actually working toward in Feb 2012 :-) | 11:49.03 |
| | kens: if we completely dropped images in condition 2, we would restore the old behaviour. | 11:49.22 |
| kens | rayjj if he can poitn me to any related bugs that owuld be good too :-( | 11:49.22 |
| rayjj | kens: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=a13600f1c241c3e36dbe4973e9d78a8934b16004 | 11:49.29 |
| kens | rayjj restore the old behgaviour, but better, because instead of pushing the clip device (and haveing it throw everything away) we'd drop the object instead. | 11:49.57 |
| Robin_Watts | kens: It follows on from: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=e448aeaf3d3d572bf4e91d9acdf3fa623ed9b6fb | 11:50.29 |
| kens | OK so that's a customer test file, anyone know which one ? | 11:50.55 |
| | Hmm I see that original commit actually added all this code | 11:51.40 |
| | Ah OK I see why hte 'old' behaviour worked, previously to Robin's optimisations we simply always stuck the clip device on, that's clearly sub-optimal | 11:53.06 |
| Robin_Watts | kens: looks like the 532 discussions at that time were about the JEITA test files. | 11:53.29 |
| kens | OK thanks for the discussion, I'll go ahead and make these changes and see what the cluster has to say (nothing I expect ;-) | 11:53.32 |
| Robin_Watts | 3rd Feb 2012, email called "Re: PDF Performance - WWTT test files" has a couple attached. | 11:54.34 |
| kens | Hmm, let me find that | 11:54.43 |
| Robin_Watts | and on the 2nd a couple more. | 11:55.01 |
| rayjj | kens: the commits prior to Robin's were from Shailesh and mention Bug 690870 | 11:55.09 |
| Robin_Watts | dives into shower. | 11:55.13 |
| | rayjj: hat might be a separate issue. | 11:55.26 |
| rayjj | Robin_Watts: probably so since that was codec issues, afaict | 11:55.44 |
| kens | Looks like it, those mention jbig2dec | 11:55.45 |
| | OK I see the files from Eric Pugh, I'll give those a quick examine before I test this change | 11:56.59 |
| rayjj | performance improvements for 532 would make sense. those WWTT files are pure text and not using the clip device would improve performance | 11:57.15 |
| kens | Indeed, I'm assuming that's what its all about. Normally this doesn't make a difference, but the test file for the new report uses glyphs, off the page, too big to cache so they come through as images instead of text | 11:58.06 |
| | OK none of those test files trigger the condition, so I assume Robin's later changes were speculative, rather than prompted by an actual test case. | 11:59.39 |
| rayjj | oh, great. peeved is unreachable. Last time this happened I needed to cycle power on my cable modem (which is now 1800 miles away) | 12:00.09 |
| kens | could be tricky..... | 12:00.34 |
| rayjj | kens: we have the WWTT files in /tests_private/pdf/PDF_1.7_ATS | 12:01.42 |
| | (the originals in case the ones from Eric were modified) | 12:02.03 |
| kens | rayjj not a problem, I used the customer ones in the mails | 12:02.07 |
| | Better to use the ones that prompted the change I think | 12:02.19 |
| Robin_Watts | kens: The did supply more files. | 12:07.41 |
| kens | Any more emails, or should I just check all the JEITA files ? | 12:08.09 |
| Robin_Watts | RE: PDF Performance - profile data - 1200 dpi 1-bpp on the 3/2/2012 from Eric | 12:09.02 |
| kens | I've actually just reordered the code, moving the 'empty' test to before the 'trivially included' test (instead of as an else clause to that test), so I'm reasonably confident about this anyway | 12:09.33 |
| Robin_Watts | kens: They suppsoedly gave us a testfiles.zip on their ftp site, but I can't find a copy of it. | 12:10.33 |
| | It might be on peeved :) | 12:10.42 |
| kens | Not to worry, I'm pretty confident with this change, and the files I have so far work. I'm assuming the clusater will test the JEITA files (since they are in test_private) so I'll just go ahead with a cluster push | 12:11.20 |
| Robin_Watts | oh, I have it here, I think. | 12:11.35 |
| | A snip at 10Meg if you want me to upload it. | 12:11.48 |
| Robin_Watts | lunches | 12:12.00 |
| kens | Hmm I htink it'll be OK without | 12:12.01 |
| | I'm confident teh 'originals' of these files are tested | 12:12.20 |
| | let me just see what the cluster makes of it | 12:12.44 |
| rayjj | kens: the jeita files are in /tests_private/jeita so they should be included | 12:14.55 |
| kens | THat's what I thought yes | 12:15.05 |
| rayjj | kens: there's a list of performance files from Eric in an email on Feb 1, 2012. Subject: RE: WWTT* 1200 dpi slowdown | 12:16.04 |
| kens | Yes Ray, I saw that, and I've tested the files I have. My changes make no difference to those. In fact my changes only affect files where the image is completely clipped out (ie a dumb file) | 12:22.15 |
| rayjj | kens: do you have strong objections to adding pageneutralcolor as a parameter ? Seems like it might have utility in the future (besides HCL and bug 695298) | 12:24.08 |
| kens | rayjj No, I don't mind particularly, but can we leave it off pdfwrite ? Its not going to be valid there or for any member of that family | 12:24.51 |
| | I just have visions of people running throgh pdfwrite and wondering why the pages they get out don't match the 'pageneutral' parameter | 12:25.46 |
| | Hmm, my chasnges made a difference in 1 file, but only with ps2write, that's strange | 12:27.10 |
| | rayjj aren't you supposed to be on vacation ? | 12:27.30 |
| chrisl | rayjj: I've made some progress on the leaking mutex issue - it's really leaking profiles. I have master running the test file with no profiles (or monitors) going unfreed - BUT, it is a boatload of changes across 10 files :-( | 12:31.03 |
| rayjj | kens: yes, but I'm trying to wrap up the performance changes for 532 that I didn't get done. Everyone else is sleeping in ATM | 12:31.26 |
| | chrisl: that'll help Shinohara-san save face (it's not a simple fix as with the gp_monitor_free that he found previously) | 12:32.36 |
| chrisl | rayjj: no, this is gc changes, reference counting changes - bloody nightmare, tbh! | 12:33.27 |
| rayjj | kens: I see -- so if I put it in with printer parameters it won't show up with vector devices | 12:33.40 |
| kens | rayjj sounds good to me | 12:33.50 |
| rayjj | chrisl: feel free to move anything to non-gc memory, BTW | 12:34.14 |
| chrisl | rayjj: part of the problem is that most of the ICC stuff is already in non-gc memory, but is referenced from gc-memory. | 12:35.19 |
| rayjj | chrisl: refererences from gc memory aren't bad -- it just means that the pointer doesn't get exposed to the GC in the structure descriptor | 12:36.14 |
| | what the GC doesn't know about, it can't mess up (or reloc) | 12:36.43 |
| chrisl | rayjj: except that the garbage collector doesn't call the object specific "free" method to free the memory, it just sweeps up the memory - so the non-gc parts don't get freed and/or the ref count decremented | 12:37.36 |
| rayjj | we should have a special test for GC memory that has the GC purposefully reloc EVERYTHING it knows about :-) | 12:37.50 |
| | that way we can look for those that assume things won't move when, in fact, they can | 12:38.22 |
| jogux | paulgardiner : I believe the configuration is correct other than the extra BOX ONE CLOUd or whatever it was Pete spotted - are you seeing other differences? | 12:38.45 |
| rayjj | chrisl: is that GC or restore that does that ? | 12:39.49 |
| chrisl | rayjj: both, since restore effectively does a mini-gc | 12:40.30 |
| paulgardiner | jogux: yes that's exactly right. I reconstructed it from the tracking sheet, removed the two options that the other commits got rid of, dealt with a deprecated option and I ended up with just the one-cloud thing being the only extra. I have commits on master | 12:40.34 |
| jogux | paul: great, thanks. I'll look. | 12:40.50 |
| chrisl | rayjj: in this case, the restore isn't *such* a problem, since mostly we're in stable_memory. | 12:41.32 |
| paulgardiner | jogux: there's a second commit with the thing we discussed yesterday to do with ALIEN_IPHONE_RELEASE overriding stuff too | 12:41.35 |
| jogux | paul: both LGTM | 12:41.37 |
| paulgardiner | ta | 12:41.43 |
| jogux | thanks for fixing my mistakes :-) | 12:41.58 |
| paulgardiner | jogux: It's an enormous pleasure for it to be in that direction for a change. :-) | 12:42.26 |
| | jogux: I'm just checking the iOS GD build. No need for any ATS checks for this, I assume? | 12:43.05 |
| jogux | paul: there's autobuild for all the ios release configs I think, which you could run, but not sure it's necessary really. | 12:43.41 |
| chrisl | rayjj: anyway, the point is, with the extent of the changes, in areas that are largely new to me, it would probably be a good idea for someone else to look over them - once I've removed my debugging code, and tidied up. | 12:44.12 |
| rayjj | darn. I just ran a cmp across all files in gs (between the customer's version and my local version) and I forgot to use >> instead of > to capture the results. The last file matched, so the output was empty :-( | 12:44.28 |
| | chrisl: probably both mvrhel and myself should look | 12:44.52 |
| chrisl | rayjj: cool. Hopefully, I'll have the master code ready for review by the end of today | 12:45.30 |
| | Then comes the fun of porting it to the customer's code...... | 12:45.57 |
| rayjj | chrisl: oh, yeah. Good thing I'm on vacation ;-) | 12:48.49 |
| chrisl | rayjj: you should say you're going somewhere with no net access | 12:49.47 |
| rayjj | chrisl: You saw the forward from Len about the latest simulator, right ? | 12:50.13 |
| chrisl | rayjj: yes - I haven't got it yet, I've been buried enough in the master code! | 12:50.44 |
| rayjj | chrisl: understood. Just wanted to make sure you knew what to start with | 12:51.25 |
| chrisl | rayjj: I'm *really* hoping this stuff hasn't changed much since 9.06, so back-porting won't be too onerous | 12:52.35 |
| rayjj | Now I have to figure out why my trivial change made the whole thing not work (it works for me on my older simulator). Only 68 files differ | 12:52.36 |
| | chrisl: oh, the blind optimism of youth ... | 12:52.58 |
| chrisl | rayjj: with the bruising on my forehead from banging my head on this for the last few days, I need to see some light at the end of the tunnel! | 12:53.51 |
| Alex_ | hi, i am developing an small app in which i use mupdf and i have a small question (new here who should i talk with ?) | 13:07.54 |
| kens | Just ask your question | 13:08.08 |
| rayjj | Alex_: some of the mupdf devs are here (but may be busy) | 13:08.27 |
| kens | Either someone will answer now, or when the relevant developer is free they will respond | 13:08.34 |
| | THe channel is logged so if you have to leave before a reply is forthcoming,you cna chekc the logs later | 13:08.53 |
| | Alex_ : you are aware the MuPDF is AGPL ? I assume your application will be compliant | 13:10.19 |
| Alex_ | well i wanna take the fz_text_block from a fz_page_block but for some reason "block->u.text;" throws an error that text can not be found | 13:10.35 |
| paulgardiner | pedro_mac: do you understand Brad's comment regarding Good Share transfering to SOG? "The IT policy will control access to the other application appropriately". Who's IT policy would that be with Good Share? | 13:10.46 |
| pedro_mac | theirs as far as Iâm aware; they are running the GoodShare server | 13:11.46 |
| rayjj | Alex_: not very specific. probably you should put a code snippet on pastebin or somewhere (point us to it) and also say what error you are getting | 13:12.03 |
| pedro_mac | glazed over at âleveragingâ.. ;) | 13:12.25 |
| paulgardiner | :-) | 13:13.08 |
| Alex_ | http://pastebin.com/DYnZcBHA a small snippet | 13:14.32 |
| Robin_Watts | Alex_: You get that error at compile time? | 13:15.00 |
| Alex_ | yes | 13:15.05 |
| | jni/mupdf.c:461: error: invalid initializer is actualy | 13:15.45 |
| Robin_Watts | fz_text_block *tBlock = block->u.text; | 13:16.13 |
| | Note the * there. It is important. | 13:16.22 |
| | Or if you really want an fz_text_block tBlock then use: | 13:16.46 |
| | fz_text_block tBlock = *block->u.text; | 13:16.57 |
| Alex_ | thx now it compiles, the part with the text field not fount is still there but it compiles | 13:17.40 |
| rayjj | Robin_Watts: fz_text_block_ only has bbox, len, cap and lines (no 'u' union) | 13:17.40 |
| Alex_ | yeah i need to reach the bbox | 13:17.55 |
| Robin_Watts | rayjj: The union is in the fz_page_block. | 13:18.23 |
| rayjj | Robin_Watts: oh, misread that. | 13:18.56 |
| Alex_ | hmm now it compiles but still can not run the project because the text field is still not found. | 13:20.23 |
| paulgardiner | pedro_mac: with the Android app, have you found an alternative way to test transfer-file requests incoming to SOG? | 13:27.06 |
| pedro_mac | paulgardiner: yes - just use the AppKinetics sample app | 13:27.36 |
| | it doesnât do edit-file though, which is the other area I need to test | 13:27.59 |
| | paulgardiner: fwiw, our GC is set up to allow access to all Good apps, all SO variants and the AppKinetics sample | 13:50.07 |
| | however⦠the existing marketplace app is controlled via the partner portal, so let me take a look at that | 13:51.43 |
| paulgardiner | pedro_mac: I imagine it's their side. You'd sort of hope that, given they suggested testing using Good Share and we'd mentioned that was why we wanted the log in, they'd have sorted this out... although given past experience... | 13:53.50 |
| pedro_mac | paul> want to try now? | 13:54.52 |
| paulgardiner | Same | 13:55.44 |
| pedro_mac | the marketplace app doesnât have transfer-file enabled. | 13:57.23 |
| | the only other thing I can suggest is that we build with a development good ID again, make sure transfer-file is enabled in our GC and give that a go | 13:58.27 |
| | (thatâs what Iâve got for android) | 13:58.39 |
| paulgardiner | But that's not working for you, right? | 13:59.35 |
| | Oh I see why your suggesting that. You thing that they might have enabled the dev good ID | 14:00.23 |
| pedro_mac | transfer-file works fine for me with the AppKinetics sample, but I canât get GoodShare to work (presumably because theyâre owned by different domains) | 14:00.26 |
| | the dev good ID is all handled by us, which is why Iâm happy we can get *that* to work ;) | 14:01.05 |
| paulgardiner | Wonderful! AppKinetics sample for iOS doesn't build. Undefined symbols that seem to be ones of ADSupport.framework, even though that framework is in the project | 14:01.11 |
| pedro_mac | Iâm much less convinced that Good have set up appropriate access for us to interoperate with the TryGoodNow domain | 14:01.34 |
| | I have vague memories that thereâs something relevant in the iOS sample readme | 14:03.16 |
| paulgardiner | Got it I think | 14:07.34 |
| | Application Access Denied, perhaps not surprsingly: what I just built is com.good.gd.example.appkinetics. My user account allows com.artifex.dev.appkinetics | 14:11.42 |
| | I guess I can just add the other version of the app to my user account | 14:12.31 |
| pedro_mac | I donât think you cn - I think Good have that registered themselves in the NOC | 14:16.34 |
| | I changed the packagename to com.artifex.dev.AppKinetics on âdroid | 14:17.04 |
| | think it mentions that in the docs somewhere | 14:17.14 |
| | (but I could be wrong :) ) | 14:17.40 |
| | Iâm fairly sure I canât set any policy in the GC for it | 14:18.04 |
| | as its a âgood appâ | 14:18.17 |
| | you already notionally have âaccessâ to the app in your user settings in our GC | 14:19.06 |
| paulgardiner | that would make sense, but it does seem to work though | 14:19.08 |
| | I've just opened the doc that appkin starts with in SOG | 14:19.33 |
| pedro_mac | did you change the GoodID too? | 14:19.38 |
| paulgardiner | I just added com.good.gd.example.appkinetics to my allowed apps. It was before that explicitly disallowed | 14:21.29 |
| henrys | paulgardiner, pedro_mac: can you guys send me work hour estimates for Good? I really think we need to be billing unless the hours are much less than what I think they must be. | 14:21.36 |
| paulgardiner | henrys: Ah! I haven't been keeping a separate tally for work specific to Good, although I can probably estimate it's been about 75% of my time since I started working on it. | 14:23.36 |
| henrys | paulgardiner: estimate is fine | 14:23.52 |
| paulgardiner | henrys: are you thinking we can bill GD for this? | 14:23.59 |
| henrys | picsel did | 14:24.08 |
| pedro_mac | henrys: sure. Weâve spent a lot of time working through issues which are probably not huge technical challenges; lot of server setups, experimentation, trial and error plus a fair amount of getting up to speed on what we already had in SO. Iâll get soem figures together but Iâd say weâre probably ~50-70% of our time on pure Good stuff. | 14:24.25 |
| | henrys: Picsel were engaged by Good when they were establishing themselves and didnât have an office viewer though - weâre in a different position now | 14:25.03 |
| henrys | pedro_mac: and your the only one at emobix working on it right? | 14:25.23 |
| pedro_mac | although their cut of the profits probably merits soem clawback of dev costs, especially as they could have been much more helpful/proactive | 14:25.39 |
| | hrnys: yup | 14:25.47 |
| jogux | yeah, afaicr I've done nothing on good, apart from install the SDK in ATS | 14:25.54 |
| henrys | pedro_mac: oh joseph has your hours on the invoice so I can use that. | 14:30.44 |
| pedro_mac | henrys: yes - the invoices have pure hours; I reckon somewhere between 50-70% of the time has been on Good server setup, getting up to speed, experimenting, testing, checking existing state of play etc and the remainder on Android Good port & some reviewing/other discussions | 14:32.45 |
| | as a conservative estimate Iâd say I could document what needs done and have someone else do the same Good setup in about 1/4 to 1//3 of the elapsed time. Especially for a partner setup I think weâd be massively more effective with a decent engineering contact in Good | 14:34.15 |
| | ie someone in engineering who we could discuss issues with and get reasonably direct answers | 14:35.00 |
| pedro_mac | stops bleating and gets back to âdroidwork | 14:35.13 |
| henrys | pedro_mac: pure hours? Joseph has everything itemized with hours for Good work split out, they may be approximate but they look reasonable. | 14:37.04 |
| pedro_mac | yes, theyâre the actual hours worked, but I meant that some of the hours are on development work weâd expect to do, but it may take a bit more effort figuring out the less productive stuff getting Good infrastructure setup | 14:38.09 |
| henrys | pedro_mac: thatâs the trouble I think richard thinks heâs the engineer. | 14:38.54 |
| pedro_mac | nods - apparently Picsel eventually got a contact in engineering to skype with, but that was late in the day | 14:39.35 |
| henrys | pedro_mac: well if the engineering is in the uk I could ask for a uk contact for hours reasons. | 14:41.37 |
| | Iâll try that. | 14:42.25 |
| pedro_mac | henrys> I did contact Good in the UK and got through to someone reasonably useful regarding the GoodShare stuff, but theyâre in a different division (they seem very fragmented between partner/bizdev/engineering) so they gave a good idea of what needs done, but that it should go through the partner contacts | 14:43.54 |
| | any more direct contact with engineers would be great :) | 14:44.14 |
| jogux | there's 10 commits on my master (all iOS) if anyone fancies a look. no rush (and I have to head home now anyway, back online in 40 minutes or so) | 14:49.10 |
| | hm. actually I probably have a bit more on device testing to go. | 14:52.20 |
| paulgardiner | henrys: I've emailed my estimate | 14:55.14 |
| henrys | paulgardiner: thanks also Iâve requested the engineering contact in the uk for time zone reasons, of course that could backfire they could be as inept or worse | 14:57.52 |
| paulgardiner | Thanks. as inept or worse would be difficult. :-) | 14:58.59 |
| | Some proportion of the work on SOG has been to do with the moment onto the development trunk and some of the commits will aid the non-G release, but that's probably accounted for by my already basing the SOG hours on 75% of the actual hours for that periodu | 15:01.15 |
| henrys | paulgardiner: by the way thanks for the Fringe recommendation Iâve started it and like it so far | 15:01.55 |
| paulgardiner | henrys: Oh oh! I so wish I could have it wiped from my memory so I could start again | 15:02.32 |
| | It just gets better and better | 15:02.50 |
| tkamppeter | henrys, did you already ask around about OpenPrinting Summit participation by Artifex? | 15:04.57 |
| paulgardiner | henrys: Linda and I are planning to watch it again from start to finish at some point, although obviously knowing all the plots up front is bound to detract from the experience | 15:05.42 |
| henrys | tkamppeter: Iâll do it today, thanks for reminding me. | 15:05.59 |
| Robin_Watts | paulgardiner: I found the final series slightly disappointing, but still worth watching. | 15:07.21 |
| | It felt 'tacked on'. | 15:07.34 |
| paulgardiner | Yeah, I guess I felt the same to some degree, but I don't know how much that was the disappointment that it finished at all. | 15:09.31 |
| | I remember some particularly good bits towards the end but that could have been from the last but one series. | 15:09.57 |
| | Hmmm. Most of Linda and my favourite series are currently inbetween seasons. Maybe now is the time to by the Fringe box set. | 15:12.08 |
| henrys | tkamppeter: Iâm not hopeful - probably not the summer time destination hot spot staffers are dreaming about. | 15:15.15 |
| tkamppeter | henrys, if everyone of the team is already booked on vacation that week we cannot do anything. Are there school holidays in the US in that week? | 15:18.08 |
| henrys | tkamppeter: schools are close july to september (approx) isnât it i the same in the UK? | 15:23.07 |
| kens | pretty much yes | 15:23.19 |
| henrys | tkamppeter: so 3 likely candidates to go probably will be doing family stuff since they have young kids. but Iâll send out the email, toronto is nice in August. | 15:24.31 |
| Robin_Watts | pedro_mac: So... as I said before, this is my current edr dump: http://pastebin.com/HZvPXssQ | 15:28.06 |
| pedro_mac | nods | 15:28.32 |
| Robin_Watts | And I've added some debug to the Edr_Style selector stuff to display the selector lists it makes and the rule sets it's hunting in. | 15:28.59 |
| | http://pastebin.com/1kLRgurT | 15:30.24 |
| pedro_mac | anything enlightening in the list? | 15:30.31 |
| pedro_mac | looks | 15:30.36 |
| Robin_Watts | So, as far as I can see, it's never looking in Stylesheet 0 | 15:31.03 |
| pedro_mac | nods. That would make sense. | 15:32.18 |
| Robin_Watts | Why? | 15:33.06 |
| | The first thing it says is that is it looking for a match out of "Drawing" and "Slide" | 15:34.15 |
| pedro_mac | I mean it makes sense given the results weâre seeing. I supsect we may not be running through all stylesheets as the eDR isnât 100% sure which ones to use | 15:34.37 |
| Robin_Watts | "Drawing" and "Slide" are defined in Stylesheet 0, but then I can't see why it wouldn't be listing the others that are also defined there. | 15:35.08 |
| pedro_mac | its possible that we donât enumerate stylesheets outwith the current section. Iâd need to trawl a bit to see though | 15:37.21 |
| | also seems unlikely for other users of stylesheets like Word | 15:37.49 |
| Robin_Watts | Also, when it lists the style rules, it lists: TxBody PH TxLevel-1 | 15:38.16 |
| | which is great, except that nowhere in the style sheet is that style rule defined. | 15:38.34 |
| | We have: MasterID-2147485618 TxBody PH TxLevel-1 | 15:38.59 |
| | and: MasterID-2147483648 TxBody PH TxLevel-1 | 15:39.24 |
| | and: NPH TxLevel-1 | 15:39.42 |
| | but nowhere with just the 3 components mentioned above | 15:39.53 |
| | So something is really screwed here. Probably my understanding of what I should be expecting. | 15:40.15 |
| | Am I right in thinking that the style rules that it's searching in should all come from one of the stylesheets? | 15:40.51 |
| pedro_mac | they should, unless the source doc has broken styles | 15:41.37 |
| Robin_Watts | how can the source doc have broken styles? | 15:42.07 |
| pedro_mac | it shouldnât, but its the only scenario where I think weâd end up having an object reference a style which wasnât in the stylesheet | 15:43.06 |
| Robin_Watts | I could understand if the source doc said "use A,B,C on this piece of text" and we searched for A,B,C and they weren't defined, but that's not what's going on here. | 15:43.17 |
| | It's not that we are trying to reference a style that's not in the style sheet. | 15:43.28 |
| | We're trying to look up a given set of selectors, and the system is saying "these are the possible rulesets I have to look against". | 15:44.05 |
| | and I can't see how it's getting those rulesets. | 15:44.22 |
| pedro_mac | it seems like MasterID_xxx should be identifying the stylesheet to use, and we should be matching against selectors in that stylesheet | 15:48.59 |
| Robin_Watts | pedro_mac: possibly that was the intent, but it doesn't address my basic concern. | 15:50.41 |
| | My understanding of the way this works is that for any given Edr object, we form the list of selectors that apply. | 15:51.42 |
| paulgardiner | pedro_mac: I think I mentioned before that there's a test app for iOS SOG that I've never been able to make work. Just tried again and it's working fine, and the tests seem to work. I can create a doc within SOG from the test app, then save back plus view or edit again. | 15:51.55 |
| | pedro_mac: doesn't help you with Android much though I guess | 15:52.12 |
| mattchz | robin/paul: would you mind taking a quick look at this please? | 15:52.19 |
| Robin_Watts | presumably if we have a Table group with a Row group inside it, and cell inside that, I'd expect us to end up with "Table Row Cell" as the list of selectors (possibly with some others in there as well) | 15:52.40 |
| mattchz | basically, is the structure sane? It's not finished (some cases missing), but i'd like to know if I'm going about it the right way (turned out much more complicated than I originally thought) | 15:52.46 |
| | http://git.ghostscript.com/?p=user/matt/mupdf.git;a=commitdiff;h=a069ab811988a699a9dd8796c6d2b76248f52f09 | 15:52.47 |
| pedro_mac | Robin_Watts: yes, but I canât see it picking up the (crucial) MasterID ; its tagged on Group idx 38, but never used in the style selector list | 15:53.28 |
| Robin_Watts | That part of the code seems to be working (or at least I haven't spotted a flaw in it yet) | 15:53.32 |
| pedro_mac | paulgardiner: good, but as you say doesnât help with android | 15:53.45 |
| Robin_Watts | The bit that has me utterly flummoxed is that the code then tests that selector set against a set of known rules. | 15:54.09 |
| | And those rules don't appear to correspond with anything listed anywhere in the Edr dump. | 15:54.30 |
| | Are my expectations here wrong? Or do they correspond and I'm just being stupid? | 15:55.00 |
| pedro_mac | just looking at âRow 2â (object 88) to work it back | 15:56.16 |
| Robin_Watts | pedro_mac: group 38 is never displayed, nor should it be. | 15:56.18 |
| | Right. The key entries are "Row 2" and "MS Word". | 15:56.36 |
| paulgardiner | mattchz: I'm just looking | 15:57.28 |
| mattchz | [the reason for all the extra classes is that various functions in AsyncTask are final, so I couldn't just subclass it, and also I wanted to not add any mupdf specifics into PageView.java] | 15:58.10 |
| kens | chrisl ping | 16:00.17 |
| mattchz | paul> ta | 16:00.25 |
| chrisl | kens: pong | 16:01.59 |
| kens | chrisl bug #695323, I wonder if there's an good way to deal with this ? | 16:02.48 |
| | The jobcreates a type 0 font by using composefont with a Type 42 descendant. | 16:02.58 |
| | pdfwrite doesn't know how to handle that. | 16:03.06 |
| paulgardiner | mattchz: working my way through. Looks good so far. Not sure why updatePageInternal doesn't pass it's cookie onto drawPage | 16:03.16 |
| kens | We can't emit it as a type 0 in PDF, ideally we'd like it to be a CIDFont type 11, but I'm not sure how to go about converting it. | 16:03.36 |
| mattchz | paul> oh, I hadn't noticed that it called it | 16:04.12 |
| kens | Hmm, I see thst Distiller emits it as a plain TrueType :-( | 16:04.30 |
| Robin_Watts | paulgardiner: It does, just not in the first case. | 16:04.35 |
| chrisl | kens: it should just convert to a TTF, then wrap the TTF as a CIDType 11 | 16:04.49 |
| kens | chrisl we see a type 0 with a type 42 descendant and bail out | 16:05.15 |
| mattchz | paul> oh yes. That's a mistake ;) | 16:05.44 |
| chrisl | kens: so how does pdfwrite handle a CIDFont with TTF outlines? | 16:06.03 |
| kens | Its a CIDFOnt so we emit it as a CIDFOnt | 16:06.16 |
| Robin_Watts | mattchz: So CancellableTaskExecutor is basically CancellableAsyncTask ? | 16:06.27 |
| kens | But we don't (apparently) have any way to convert, wheren type 42 outlines are supplied | 16:06.40 |
| chrisl | kens: but a CIDFont with TTF outlines in PDF boils down to a TTF, wrapped up with the CIDFont information | 16:07.18 |
| mattchz | robin> basically yeah. But the actually work of the task, and how to cancel it, is delegated to a CancellableTaskDefintion | 16:07.29 |
| kens | chrisl, true, but we don't have a CIDFont in that case, just a font | 16:07.47 |
| Robin_Watts | mattchz: Yes. Just pondering whether CancellableAsyncTask and CancellableAsyncTaskDefinition would be nicer names. | 16:08.01 |
| mattchz | Robin> I think they probably would. | 16:08.11 |
| chrisl | kens: so it *should* be possible to convert the Type42 to TTF, and emit it - I assume using Identity encoding | 16:08.28 |
| mattchz | although I steered away from CancellableAsyncTask, because that sort of implied it was a sub-class, which it isn't. | 16:08.41 |
| | (ideally it would be, but some methods, e.g. cancel() are final) | 16:09.26 |
| kens | chrisl I'm not sure, we have a CMap for it in the type 0 font | 16:09.35 |
| kens | thinks this is too much at this time of night | 16:09.49 |
| Robin_Watts | mattchz: We don't override cancel though? | 16:10.09 |
| mattchz | I would do. Instead cancelAndWait() is a wrapper around the asynctask's cancel. | 16:10.46 |
| chrisl | kens: the lack of a CMap is why I assumed you'd resort to an Identity encoding | 16:10.51 |
| Robin_Watts | so we could subclass it, and just not call cancel. but that's nasty. | 16:11.09 |
| kens | But we have a CMap, its required in order to use composefont | 16:11.10 |
| mattchz | robin> I felt it was nasty. But on reflection, I'm not sure if it's nastier than composing it as I have. | 16:11.27 |
| | either way isn't nice. | 16:11.35 |
| | I could just remove 'final' as we have our own source for AsyncTask :) | 16:11.46 |
| chrisl | kens: okay, well use the CMap then..... | 16:11.56 |
| kens | Yeah, easier said than done maybe. Like I said there is *no* code for this at present, we don't expect to handle ti at all. | 16:12.26 |
| | I've altered the bug to an enhancement and I'mgoing ot leave it for now | 16:12.40 |
| chrisl | There must be code to extract the CMap from type 0 font? | 16:13.00 |
| paulgardiner | mattchz: looks like it's going the right way to me. I'm pleased that you are keeping PageView free of MuPDF specifics. One day that may be giving us more hassle that it's worth, but good to maintain it if possible | 16:13.14 |
| kens | chrisl yes, probably, but not when its a type 42 font | 16:13.30 |
| | We use various 'encode' routines to get the character code, we don't handle the CMap directly at all | 16:13.57 |
| mattchz | paul> indeed. It's a really nice setup, wouldn't want to spoil it. | 16:14.10 |
| paulgardiner | I like Robin's name changes and perhaps it doesn't matter that it isn't a subclass seeing as it has a very similar signature | 16:14.21 |
| chrisl | The CMap would be in the Type 0 not the Type 42 | 16:14.22 |
| Robin_Watts | mattchz: Keeping AsyncTask vanilla seems good to me. | 16:14.34 |
| paulgardiner | mattchz: but happy for that to be your call. | 16:14.41 |
| mattchz | cool, ok, so I'll rename. | 16:14.44 |
| kens | chrisl yes, but we need the CID, and the various pieces of code that do that, don;t, when its a Type 42. | 16:14.55 |
| mattchz | do you think I should just subclass and use another name like nativeCancelAndWait() | 16:15.07 |
| kens | I'll need to refer back to the non-composite case to see how to get a CID | 16:15.12 |
| mattchz | ? | 16:15.15 |
| pedro_mac | Robin_Watts: Iâm slightly bemused by the style matching too. The way I see it: | 16:15.48 |
| paulgardiner | subclass and use a new name seems fine to me. I think I had to do that before at some stage | 16:15.48 |
| Robin_Watts | mattchz: That would be fine for our purposes, but would leave the potential there for people to try to reuse the code and try to call cancel(); | 16:15.50 |
| mattchz | robin> yeah, that's what I was thinking. | 16:16.02 |
| chrisl | kens: Hmmm, pdfwrite really sucks :-( | 16:16.06 |
| pedro_mac | id 81 (MS Word) is Slide Drawing spTree PH TxBody TxLevel-3 | 16:16.12 |
| kens | chrisl, you only just noticed ? O.O | 16:16.21 |
| paulgardiner | There used to be a SafeAysyncTask that was done that way | 16:16.26 |
| pedro_mac | id88 (Row 2) is Slide Drawing spTree NPH DefaultText TxLevel-3 | 16:16.34 |
| mattchz | robin/paul> also, it would be easy to accidentally call cancel() based on the autocompleting. | 16:16.39 |
| chrisl | kens: no, but I thought it warranted the observation at this stage | 16:16.56 |
| mattchz | paul> oh, I wrote a SafeAsyncTask class once :) | 16:16.58 |
| kens | :-) | 16:17.15 |
| mattchz | one that survived activity rotation, or something iirc | 16:17.16 |
| Robin_Watts | pedro_mac: Yes, that sounds right. | 16:17.30 |
| mattchz | it was a nightmare :-d | 16:17.33 |
| paulgardiner | Wasn't aware that it had been removed from MuPDF but perhaps we no longer needed it because of taking on the source of the vanilla one | 16:17.36 |
| Robin_Watts | and I would have hoped that the first one would have picked up: PH TxBody TxLevel-3 | 16:17.56 |
| paulgardiner | Can you make cancel private or within the subclass? | 16:18.03 |
| Robin_Watts | and the second would have picked up: NPH TxLevel-3 | 16:18.23 |
| paulgardiner | Anyway. Got to go. | 16:18.32 |
| pedro_mac | Robin_Watts: perhaps the eDR styling isnât quite following CSS rules, but should be pretty close; assuming our rules are treated as descendent I donât see how our PH or NPH matches any of the rules as theyâre not in order (eg TxBody PH TxLevel-3 | 16:18.33 |
| chrisl | kens: so are you thinking maybe we could convert the Type42 to a CIDType11 at the PS level? During the composefont? | 16:18.34 |
| kens | chrisl, I had thought that, but I've discounted it | 16:18.53 |
| Robin_Watts | pedro_mac: Ah, right. I asked yesterday if ordering mattered, and was told no :) | 16:19.01 |
| chrisl | I think we'd struggle to make that reliable - plus all those PS files that poke around inside the already defined font would get upset | 16:19.29 |
| Robin_Watts | but I can frob the ordering in the style definitions to match, I believe, so I don't think that's a showstopper. | 16:19.33 |
| kens | chrisl the spec says its supposed to be a type 0 | 16:19.48 |
| | So I've made it an enhancement and I'm leaving it at that. THe other problem they raised is something to do with /.notdef glyphs :-( | 16:20.18 |
| Robin_Watts | pedro_mac: do you see my point about the stylerules that are being printed out not matching the stylerules that are in the edr? | 16:20.30 |
| chrisl | kens: O thought type - was the composite font | 16:20.48 |
| | kens: I thought type 0 - was the composite font | 16:21.00 |
| kens | It is, yes, sorry, I'mlooking at multiple problems at the same time | 16:21.30 |
| pedro_mac | its possible it doesnât work that way, but thatâs like me specifying a âp buttonâ rule that also matches a âbutton pâ construct | 16:21.38 |
| kens | Like I said, I discounted doing the conversion | 16:21.42 |
| | We should deal with the type 0 and convert to a CIDFont | 16:21.57 |
| pedro_mac | deliberately uses arcane HTML elements in the example ;) | 16:22.13 |
| chrisl | Yeh, I think pdfwrite just needs to handle it - a Type 42 descendant is, IIRC, legal | 16:22.16 |
| Robin_Watts | pedro_mac: I think that you are right, and ordering matters in the current code. | 16:22.32 |
| kens | But its not going to be trivial and I'mdrowning under multiple bug reports now, so I'm leaving it as an enhancement. The output is 'correct' visually, the customer can bleat about it being non-searcahble all they want | 16:22.43 |
| pedro_mac | Robin_Watts: I can believe it doesnât honour the order, but Iâm not assuming it ... | 16:22.45 |
| Robin_Watts | Whether it should matter is not something I feel qualified to comment on. | 16:22.46 |
| | pedro_mac: I think it does, cos of looking in the Edr_Style_matchRule implementation :) | 16:23.09 |
| chrisl | kens: Does it actually use multi-byte char codes? | 16:23.16 |
| kens | Ah, and they are a 'low support' customer, and its their own application generating the PostScript :-) | 16:23.26 |
| Robin_Watts | Edr_Style_matchRules, even. | 16:23.29 |
| kens | chrisl yes, and no. The codes are 2 byte, and the first byte is always 0 | 16:23.52 |
| pedro_mac | In any case, it doesnât seem to be caring about the MasterID which is the key factor in getting the right style | 16:23.54 |
| chrisl | kens: ugh, of course :-( | 16:24.13 |
| kens | Why anyone would define that as a type 0 font escapes me..... | 16:24.28 |
| chrisl | Monkey see....... | 16:24.43 |
| kens | Ah they do have some higher CID in the CMap | 16:24.58 |
| | chrisl I would guess thiat they've noticed they need to support multi-byte languages and this is the way they've chosen to do it. Since they are a low support customer, and create hte PostScript themselves I plan to leave it at 'make a CIDFont type 11 instead' for the present. Type 0 fonts with type 42 descendants are really rare | 16:27.18 |
| chrisl | kens: Yes that is true, and it should be no harder to make a Type 11 than a Type 42...... | 16:28.21 |
| kens | Of course their other test file is nice and simple (not) 3 different fonts, all defined as type 0, and a page full of text, all to show that their 'space' glyph is being rendered as a /.notdef | 16:28.24 |
| pedro_mac | Robin_Watts: I think thereâs a fundamental issue with the placeholder stuff in that the actual slide oject picks up its styling relative to the stylesheet, but thereâs nothing telling the placeholder objects that they have a style from that stylesheet. We donât have any explicit stylesheet selection code, and the element itself isnât tagged with the appropriate masterid selector | 16:28.32 |
| chrisl | kens: so what are they complaining about with that one? | 16:29.01 |
| kens | THey have space glyphs and they are rednering (only with pdfwrite) as a square with a cross in it.Looks pretty much like a /.notdef to me. | 16:29.30 |
| | But when sent to a rendering device, it comes out without making marks | 16:29.48 |
| | I think its 'something' to do with /.notdef glyphs but I can't prove it yet. Again its their own PostScript. | 16:30.22 |
| Robin_Watts | pedro_mac: There are a plethora of styles applied to the Edr objects, which are presumably intended to solve this. | 16:30.23 |
| | slide2147485618-ph-1 slide2147483648-ph-body id='slide316-ph-1' for a start. | 16:30.39 |
| kens | OMG it looks like they keep on redefining the fonts | 16:30.51 |
| chrisl | kens: possibly just set the user param to not rendering TTF notdefs? | 16:31.05 |
| Robin_Watts | and if it was just that those were set up badly I'd be happier, cos we could fix them. | 16:31.21 |
| kens | chrisl it doesn't render when going to the display | 16:31.29 |
| | (the original PostScirpt that is) | 16:31.40 |
| | OK I need to run off, back to this fun tomorrow :-( | 16:32.13 |
| chrisl | kens: is pdfwrite rendering these to a Type 3? | 16:32.17 |
| kens | chrisl apparently not, type 1 fonts | 16:32.35 |
| chrisl | Ah, okay - we'll talk more tomorrow | 16:32.51 |
| Robin_Watts | pedro_mac: But I cannot get past the fact that when I print the sets of style rules that it's matching against, they don't correspond to any sets of style rules I see in the edr. | 16:33.38 |
| kens | THese ones appear to be CFF fonts, whicih is why they come out as type 1. They still munge them to make type 0 out of them though | 16:33.38 |
| Robin_Watts | pedro: Take for example Group, idx = 4 | 16:34.59 |
| | This is the first group we meet when rendering the file. | 16:35.14 |
| pedro_mac | yup | 16:35.25 |
| Robin_Watts | We get a call to Edr_Style_createSelectorList and that returns "316 Slide" | 16:35.42 |
| | which seems reasonable to me. | 16:35.46 |
| chrisl | rayjj, mvrhel_laptop: here are my changes for the cust 532 "mutex" problem: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=d91bec190 | 16:36.48 |
| Robin_Watts | We then get a call to Edr_Style_matchRules to try to match that SelectorList against the style rules. | 16:36.48 |
| | And the style rules it lists are "Drawing Slide" | 16:36.58 |
| | oh, wait... I've just spotted something in the code. | 16:37.06 |
| | There is a call to Edr_Style_matchRules which calls with &sortedRules->single. | 16:38.01 |
| mvrhel_laptop | chrisl: great. I will look this over today | 16:38.07 |
| Robin_Watts | I wonder if that's rules with a single entry in. | 16:38.15 |
| pedro_mac | so you only match the first? | 16:38.23 |
| Robin_Watts | The single entry rules from stylesheet 0 would indeed be "Drawing" and "Slide" | 16:38.44 |
| pedro_mac | interesting | 16:38.45 |
| chrisl | mvrhel_laptop: did you get/do you want the test file to go with it? | 16:39.10 |
| jogux | robin: did I confuse you with my statement about ordering? the ordering of rules shouldnât matter, the ordering within selectors should. | 16:40.08 |
| Robin_Watts | jogux: Right. | 16:40.24 |
| jogux | should the pastebin have extra logging in it? I donât see it | 16:40.57 |
| mattchz | does anyone object if I had .DS_Store to the .gitignore in the mupdf repo? | 16:41.02 |
| | s/had/add/ | 16:41.11 |
| Robin_Watts | Not at all. | 16:41.23 |
| | jogux: The debug output is in the second pastebin. | 16:41.38 |
| jogux | robin: the rules it matches against have, I think, been reordered to have the most specific last. | 16:41.41 |
| Robin_Watts | jogux: I think the rules have been reordered so they can be binary searched in :) | 16:42.07 |
| | but it's not the ordering of the rules that bothers me. | 16:42.17 |
| jogux | oh. urm. interesting. | 16:42.17 |
| Robin_Watts | Edr_Style_matchRules binary searches on the first entry of the selector list. | 16:42.45 |
| | but I'm not even concerned about what matches and what doesn't at this point. | 16:42.59 |
| jogux | hehe | 16:43.05 |
| | your first statement set me wondering if thereâs a nasty non-CSS hack for PPT somewhere. | 16:43.27 |
| Robin_Watts | I'm concerned that the rule sets it is searching in don't match up with my expectations. | 16:43.35 |
| mvrhel_laptop | chrisl: I don't have a test file | 16:43.51 |
| chrisl | mvrhel_laptop: I'll forward the e-mail with the attachment - just in case you feel need to poke in the debugger | 16:44.56 |
| mvrhel_laptop | ok thanks chrisl | 16:45.28 |
| chrisl | mvrhel_laptop: as it's dealing with gc memory, and reference counting and those interacting, it might be hard to follow "statically" | 16:46.14 |
| mvrhel_laptop | fun! | 16:47.10 |
| chrisl | Oh, it's a barrel of laughs! | 16:48.00 |
| Robin_Watts | jogux: You think that maybe the stylerules are being bent in a ppt specific way ? | 16:50.20 |
| jogux | It seemed like a possibility. But I canât see any code that would support that idea. | 16:50.51 |
| Robin_Watts | If I'm right about the single rules, that would explain why we only see "Drawing" and "Slide" in the rootRules list. | 16:51.39 |
| | But nothing explains why the parentRules list doesn't include (say): "MasterID-2147483648 TxTitle PH TxLevel-1" and just has "TxTitle PH TxLevel-1" | 16:52.49 |
| el_mendi | Robin_Watts: Hi, I'm trying to save the document once I have inserted the image. I'm using the function core.save() but it doesn't work, it calls the function pdf_clean_page_contents like 10 times, and finally I got an empty page | 16:53.05 |
| Robin_Watts | el_mendi: I'm a bit busy at the moment. | 16:53.41 |
| | but AIUI, from what you were saying the other day, you can write your image into the document, but you have to change page away and back again before it's redrawn properly? | 16:54.12 |
| el_mendi | Ok np, I will try it later, thank you | 16:55.17 |
| jogux | robin_watts: indeed, that sounds odd. I think Iâd need to try adding my own debug, I canât make sense of it from just reading the code. Iâm happy to do so (but in the morning, the bbq is on :) ) | 16:56.05 |
| Robin_Watts | jogus: Yeah, I think I'm going to have to admit default and pull in help to solve this. | 16:56.25 |
| | and it shouldn't be pete. | 16:56.29 |
| | have a good bbq. Thanks to you both | 16:56.38 |
| jogux | this area did get heavily optimised in the browser work, which makes the code a lot more complicated than it really needs to be for powerpoint :( | 16:57.11 |
| | we really shouldâve listened to Pete more when he wanted to pull edr/layout back to being a lot more format specific, rather than trying to be one size fits all. :( | 16:58.33 |
| Robin_Watts | jogux: I'm a sucker for 1 size fits all, most of the time. | 16:59.10 |
| | el_mendi: First we should solve the redraw issue, then we can think about the saving one. | 16:59.35 |
| | The redraw issue is to do with the fact that we keep a cached displaylist for the page. | 16:59.51 |
| | And if you alter the page, you need to redo that displaylist. | 17:00.00 |
| pedro_mac | jogux: iirc I was keen to keep a one-size-fits-all interface, but have more plug-in bits which understood the formats and reused some of the underlying stuff for layout etc rather than pretend that we could emulate behavior of all the apps without any explicit knowledge. Its a pretty complex thing to do really | 17:01.45 |
| Robin_Watts | pedro_mac: Yes, that makes sense. | 17:02.10 |
| | el_mendi: To do that you're going to need to fiddle in mupdf.c, the JNI implementation. | 17:03.25 |
| el_mendi | Which JNI implementation in particular? | 17:04.43 |
| Robin_Watts | You're going to need to add a new JNI interface. | 17:04.59 |
| el_mendi | The redraw is done but only when I move two pages forwards or back wards and then came back | 17:05.20 |
| Robin_Watts | something like: MuPDFCore_dropPageCache(JNIEnv *env, jobject thiz, int page) | 17:05.22 |
| | If you look at MuPDFCore_gotoPageInternal | 17:05.42 |
| | Basically you want to copy the top of that function all the way down to the drop_page_cache() call. | 17:06.14 |
| | You want to rename that to be MuPDFCore_dropPageCache, and you want to alter the logic so that it searches through glo->pages[i].page looking for the page in question. | 17:07.14 |
| | All the 'furthest' stuff can go. | 17:07.32 |
| | and if you match the page, you don't want to return, you want to call drop_page_cache on it. | 17:07.53 |
| | Then you'll need to expose that in MuPDFCore (just copy the code for gotoPageInternal) | 17:08.26 |
| | then you'll need to arrange to call that after you write to a page. | 17:08.48 |
| | Possibly you may need to call gotoPageInternal again as well. | 17:09.07 |
| | rayjj_: So, apparently you're supposed to be writing an "embedding gs" document? | 17:11.52 |
| mvrhel_laptop | hi rayjj_ | 17:11.52 |
| Robin_Watts | and I'm supposed to be writing the corresponding mupdf one. | 17:12.01 |
| | What's the actual spec of these documents? Target audience? subjects covered? | 17:12.16 |
| pedro_mac | heads home - catch you later | 17:13.50 |
| rayjj | chrisl: I'm looking over your patches (just started). When you start with their simulator, if you cd to the gs2 directory, then do 'git init ; git add *' right afer unzipping it, you should be able to 'git am' the patches I sent in the email to Len (in the .zip) Or just unzip that file in your gs2 directory and it'll make sure you are starting from where I was | 17:14.34 |
| chrisl | rayjj: okay, thanks, I'll get the new sim running first thing in the morning | 17:16.23 |
| rayjj | Robin_Watts: I think the target gs audience is color and monochrome printers with and without ASIC support for object rendering, color management and/or halftoning. Topics should include all the usual questions: ROM footprint, RAM footprint (disk and diskless), performance issues ... | 17:17.01 |
| Robin_Watts | rayjj: Gotcha, thanks. | 17:17.36 |
| rayjj | Robin_Watts: the mupdf audience expands to include projectors, and should mention possibility of banding, and suitability for low-end (inkjet?) printers | 17:18.23 |
| Robin_Watts | yeah. | 17:18.59 |
| rayjj | Robin_Watts: I'd also highlight the ability of mupdf to print from http: accessible files | 17:19.07 |
| | Robin_Watts: the ROM footprint should probably be minimal (no http:, no js, etc.) but spec for with http: would be interesting (IMHO) | 17:20.49 |
| Robin_Watts | rayjj: I was considering writing this on the Twiki. | 17:21.25 |
| mvrhel_laptop | bbiab. taking daughter to dentist | 17:21.39 |
| rayjj | mvrhel_laptop: hi. If you can also have a look at chrisl's patches, I'd appreciate it | 17:21.52 |
| | we'd appreciate it :-) | 17:22.05 |
| Robin_Watts | That means it can be easily tweaked by anyone, and parts of it can be reused in other documentation efforts. | 17:22.09 |
| | You might want to consider that for the gs one too. | 17:22.28 |
| rayjj | mvrhel_laptop: my kid's dentist has wi-fi so I can work there :-) | 17:22.39 |
| | Robin_Watts: sounds like a good idea | 17:22.54 |
| Robin_Watts | rayjj: Does he do fillings that pick up wifi? :) | 17:22.58 |
| | chrisl: asking customers to "bare with us" is an invitation to simultaneous nudity. I think you mean "bear with us" :) | 17:25.51 |
| chrisl | Crap, I keep doing that - something Freudian there..... | 17:26.33 |
| el_mendi | Robin_Watts: I've copied gotoPageInternal and erased all the "furthest", the code is here: http://pastebin.com/tuXMvvUr but i have the same problem. | 17:29.56 |
| Robin_Watts | el_mendi: Eh? | 17:30.21 |
| Gigs- | update on my malware... we only had one person actually get infected... he had acrobat 9 installed gugh | 17:30.28 |
| Robin_Watts | You've not done what I said. | 17:30.28 |
| | You've copied far too much of the function, and in the case where you find the page (in the initial for loop) you exit. | 17:31.05 |
| | That's where you should be calling drop_page_cache(). | 17:31.16 |
| el_mendi | aaaaaaahhhh | 17:31.21 |
| | inside the loop | 17:31.25 |
| Robin_Watts | yeah. THen lose everything after the loop. | 17:31.51 |
| Gigs- | Robin_Watts: my favorite customer communication snafu is using quotes for emphasis .... "Absolutely" no solicitation.... so... maybe some solicitation allowed? | 17:31.51 |
| el_mendi | ah ok ok | 17:32.04 |
| | Robin_Watts: Like this? http://pastebin.com/KFMmtZTi | 17:44.02 |
| | Do I need to remove the return call? | 17:44.41 |
| Robin_Watts | el_mendi: You can probably lose the glo->current = i, and and just use i in it's place in the next line. | 17:44.57 |
| | The return won't hurt, but you can remove it if you prefer. | 17:45.08 |
| | Now, it occurs to me that you might be calling this from within the C rather than within the java ? | 17:45.36 |
| el_mendi | no, I am calling this from MuPDFCore | 17:46.47 |
| Robin_Watts | ok, that's fine then. | 17:47.21 |
| el_mendi | but It doesn't work | 17:47.53 |
| | it is like the cache is not updated | 17:48.21 |
| Robin_Watts | Are you passing in 0 or 1 for the first page? | 17:48.47 |
| el_mendi | An I need to go two or more pages forward and come back | 17:48.57 |
| | what? | 17:49.13 |
| Robin_Watts | When you modify the first page of your document, are you calling MuPDFCore.dropPageCache(0) or MuPDFCore.dropPageCache(1) ? | 17:50.02 |
| | and after you update the page, try zooming the page rather than flipping forwards and backwards. | 17:51.12 |
| el_mendi | If I zoom it appears,but when I zoom out it disappears again | 17:52.13 |
| Robin_Watts | el_mendi: OK, so that means the call is working, but the bitmaps are not being regenerated. | 17:52.40 |
| el_mendi | the page I am calling is mPageNumber from MuPDFPageView | 17:53.15 |
| | I am calling that page to save the image and now also to redraw it | 17:54.00 |
| Robin_Watts | OK, so you're calling the right number. | 17:54.15 |
| | The problem is just that we need to invalidate the cached bitmaps on the view. | 17:54.32 |
| el_mendi | yes | 17:54.45 |
| Robin_Watts | This is something that needs to happen in the java, and paulgardiner is the guy for this. | 17:54.47 |
| el_mendi | And is he here right now? | 17:56.01 |
| Robin_Watts | I suspect not. | 17:56.39 |
| el_mendi | ok | 17:56.53 |
| | and for saving the document It is neccesary to redraw the page? | 17:57.12 |
| Robin_Watts | I can't immediately see why saving the document wouldn't just work. | 17:57.28 |
| | I was hoping that in making it redraw the page we'd spot a problem that would make saving the document work :) | 17:57.48 |
| | but definitely we should solve that first. | 17:57.57 |
| | Again paulgardiner understands the way the android app does saving better than me. | 17:58.15 |
| | It's 7pm here now. You'll do better to come earlier tomorrow. | 17:58.43 |
| el_mendi | Ok thank you | 18:04.50 |
| rayjj | hmm... Steve C actually reads my emails. My comment about them not incorporating patches from us was noticed. I hope it doesn't create problems | 18:06.37 |
| | but it is frustrating to do the work and find out it's sitting aside for unspecified "we had some problems with that/those" | 18:07.27 |
| mattchz | nn all | 18:07.40 |
| rayjj | mattchz: nn | 18:07.48 |
| el_mendi | Robin_Watts: I just managed to redraw the page. I just called the function refresh(boolean) from MuPDFReaderView | 18:28.17 |
| | U.U" | 18:28.28 |
| Robin_Watts | el_mendi: Ah! I knew there was probably a simple answer :) | 18:28.38 |
| | So, I don't see why you're not getting the document saved when it says "Would you like to save changes?" and you say yes. | 18:29.11 |
| el_mendi | But before I made what you told me before that function didn't work | 18:29.11 |
| Robin_Watts | el_mendi: Indeed, refresh wouldn't have worked without binning the page_cache. | 18:29.38 |
| el_mendi | The problem is that when I exit the document it doesn't ask me | 18:29.45 |
| Robin_Watts | el_mendi: Ah, right. | 18:29.56 |
| | That may be simple to solve. | 18:30.00 |
| | There is a mechanism somewhere for saying "this document is dirty". | 18:30.20 |
| | We use it when we fill in forms etc. | 18:30.31 |
| | paulgardiner is again the guy who would know. | 18:30.43 |
| el_mendi | Yes, I've saw something like that but now i don't find it | 18:30.46 |
| | seen* | 18:30.56 |
| | sorry for my english :( | 18:31.05 |
| Robin_Watts | core.hasChanges looks promising. | 18:31.41 |
| el_mendi | Thank you for everything, I will look for it harder | 18:31.43 |
| | But that function just returns if has changes or not.. | 18:32.07 |
| | I think | 18:32.15 |
| jogux | robin_watts: btw, could you push whatever you (inc debugging) have to your repo if you've not already? | 18:33.08 |
| Robin_Watts | jogux: Ah. I was midway through that and got distracted. Just a mo. | 18:33.28 |
| | el_mendi: Maybe we'll need to tweak something there. | 18:33.38 |
| | jogux: Pushing now. | 18:34.50 |
| jogux | robin_watts: great, thanks. I still have a couple of iOS things to investigate/test/fix, but they're not urgent so I'll start on this in the morning. | 18:35.35 |
| Robin_Watts | Thanks. | 18:36.00 |
| jogux | [and I still need to do the windows ATS client, been putting that off a while :) ] | 18:36.05 |
| Robin_Watts | If you can figure out what needs doing, maybe I can jump back in again. | 18:36.20 |
| | I am finding this whole thing hard to get traction on :( | 18:36.40 |
| | Give me a wasp bug or something :) | 18:36.51 |
| jogux | shall keep you up to date on my findings. I suspect it's going to take me at least a couple of hours to get my head around it. | 18:40.53 |
| | hehe | 18:40.54 |
| Robin_Watts | orders of magnitude faster than me :( | 18:41.34 |
| jogux | it'd be longer if you hadn't already figured out the powerpoint side and what needs to be done :-) | 18:42.21 |
| el_mendi | Robin_Watts: I change the property "dirty" from the pdf_document varable and now it asks me if i want to save the document. But when I reopen it, the page is empty, it has removed everything form the page. | 18:43.56 |
| | from* | 18:44.15 |
| Robin_Watts | jogux: Artifex2014.pptx and Art5.pptx (the original, and the cutdown files) are in my casper homedir. | 18:46.23 |
| | el_mendi: We need paulgardiner to continue this discussion I suspect. | 18:46.37 |
| el_mendi | Hahaha, ok, thank you | 18:47.11 |
| jogux | robin_watts: thanks | 19:02.31 |
| Robin_Watts | el_mendi: In one of the commits you applied, there was a typo. | 19:11.05 |
| | In pdf-device.c line 1388 in pdf_new_pdf_device | 19:11.28 |
| | the line should be: pdev->buffer = pdf_keep_buffer(buf); | 19:11.36 |
| | not pdf_keep_obj | 19:11.41 |
| | bah. | 19:13.40 |
| | fz_keep_buffer(buf); | 19:13.48 |
| | sorry | 19:13.49 |
| el_mendi | And what does it? | 19:13.57 |
| Robin_Watts | fz_keep_buffer(ctx, buf); | 19:14.19 |
| | I'll get there eventually. | 19:14.24 |
| | el_mendi: Maybe nothing. | 19:14.32 |
| | but it'll stop a warning. | 19:14.45 |
| el_mendi | ok! | 19:14.59 |
| mvrhel_laptop | ok. v2 code is all written now to test if if actually creates proper v2 profiles | 22:12.22 |
| | Forward 1 day (to 2014/06/20)>>> | |
IRC Logs