| <<<Back 1 day (to 2013/10/07) | 2013/10/08 |
mvrhel_laptop | found my spot color issue which was due to overprint simulation goof ups in the transparency code | 04:43.07 |
| will fix tomorrow. caught a cold and need sleep | 04:43.18 |
kens | aha chrisl sneaked in while I was getting coffee | 07:59.10 |
| chrisl I need some help today with TrueType font metrics if you can spare me some time please | 07:59.37 |
chrisl | I'm still feeling decidedly under the weather, I'll help if I can..... | 08:00.00 |
kens | I'm still on the track of this customer problem, and I've now come to the conclusion that the reason I can't solve the problem in pdfwrite is because there *is* no problem in pdfwrite.... | 08:00.45 |
Robin_Watts | http://www.xkcd.com/ | 08:00.46 |
kens | Yeah, I commented on that yesterday Robin_Watts | 08:01.00 |
| chrisl let me mail you a file, I'm not sure if yo uhave it or not | 08:01.14 |
Robin_Watts | kens: Ah, I missed that yesterday for some reason. | 08:01.27 |
kens | tor7 grinned about it | 08:01.43 |
| I shoudl have zipped the file, its bigger than I thought | 08:02.02 |
chrisl | I find that xkcd just a *little* close to the knuckle to actually be funny! | 08:02.09 |
kens | OK chrisl if you run the file I sent once with pdfwrite and once with the display device you'll see a load of numbers printed on teh back channel | 08:02.53 |
| The important ones are the last set, the pair of arrays. | 08:03.18 |
| These are the numbers passed into, and out out of, CDevProc | 08:03.37 |
| If you compare the numbers from the display device to the pdfwrite ones you will see thay are quite different, especially the 3rd and 4th numbers | 08:04.12 |
chrisl | Seems to be taking a while to get here | 08:04.22 |
kens | My fault, its a 600k file and I thought it was small so I didn't zip it | 08:04.42 |
| You 'may' have the file its teh 8f6459-13.ps one | 08:05.02 |
| Anyway, the whole source of the problem is that the 4th entry in the array is *way* too big in the pdfwrite case, nearly 3 times bigger than it should be. | 08:05.46 |
| The 'culprit' if I can call it that, is in zchar42.c, zchar42_et_cache() at around line 143 | 08:07.14 |
| THe comment here is : | 08:07.33 |
| which stretch subglyphs. Uniting with FontBBox helps. | 08:07.34 |
| The comment here is : | 08:07.53 |
| " /* Note: The glyph bbox usn't useful for Dynalab fonts, | 08:07.54 |
| which stretch subglyphs. Uniting with FontBBox helps." | 08:07.54 |
| And it throws away the value from the glyph and substitutes the fontBBox value. WHIch is *much* too large for this glyph. | 08:08.34 |
| So, the question for me then is how does this not cause a problem when rendering, how come the values passed to CDevProc are OK when trendering, but not when running pdfwrite. | 08:09.33 |
chrisl | Well, we probably don't use that code when rendering (FAPI), but FAPI does the same thing with the BBox, so....... | 08:10.23 |
kens | I tried with -dDisableFAPI and got yet another different set of numbers (but ones which work as well) | 08:10.57 |
| and teh -dDisableFAPI *does* go through that code | 08:11.26 |
| Oh, but in this case the FontBBox is different ! | 08:11.47 |
| Oho! If I set -dDisableFAPI with the pdfwrite case, then the numbers look correct | 08:12.44 |
chrisl | Hmm, in the FAPI code, that BBox expansion is limited to non-CID fonts..... | 08:13.31 |
kens | Yes, its somethgin to do with FAPI, the FontBBox isn't 'correct' when FAPI is enabled. Looks to me like its set for a 2048x2048 design grid | 08:13.32 |
chrisl | Erm, I don't think FAPI sets the FontBBox, I'll have to check | 08:14.36 |
kens | Its different with -dDisableFAPI, and its correct. Maybe FAPI *should* change the FontBBox | 08:15.12 |
chrisl | Arg, no it does set it - or "refines" it, which I never understood! | 08:15.26 |
kens | I think you are correct about FAPI not uising this code though. | 08:16.25 |
chrisl | FAPI calls zchar_set_cache() itself | 08:16.51 |
| If you look at gs_fapi_prepare_font() it's got come crazy code in it which we talked about ages ago, and couldn't fathom it out | 08:17.46 |
kens | Hmm, well I get here from pdfwrite because I'm executing the CDevProc, which is triggered by returning to op_show_continue_dispatch() with a code of '3' | 08:17.57 |
| which source file is that ? | 08:18.40 |
chrisl | gxfapi.c line ~320 | 08:18.57 |
| the size/size1 nonsense | 08:19.24 |
kens | Yes, I'm looking at it now | 08:19.44 |
| At the moment its all Greek to me.... | 08:19.52 |
| Let me run the display device and this file to see what happens. BTW did you get the test file yet ? | 08:20.09 |
chrisl | No, hasn't arrived | 08:20.49 |
kens | :( | 08:20.58 |
| Oh, I sent it to the wrong chris, oops | 08:21.26 |
chrisl | That wouldn't help! | 08:21.37 |
kens | Sent it again | 08:22.07 |
chrisl | Okay, FAPI is using the FontBBox straight out of Freetype | 08:22.32 |
kens | And if I do that, then it works. I'm inclined to ditch the craziness in there with 'unifying' the fontBBox | 08:23.14 |
| But I'm worried by the DynaLab comment | 08:23.29 |
| And teh FontBBox is really wrong as well | 08:24.05 |
chrisl | What happens if you run pdfwrite at, like, 144dpi? | 08:24.37 |
kens | With that code there ? its wrong in exactly the same way, I'm running at 72 dpi at the moment | 08:25.05 |
| pdfwrite seems to be doing all the right stuff with the numbers its given, the problem is that the numebrs themselves are wrong. | 08:25.29 |
chrisl | OKay, I've got the FAPI/FT code doing some juggling with scaling and stuff, and I wondered if the bbox wasn't being scaled properly, but that suggests not | 08:26.16 |
kens | Hmm, whre are you looking now ? | 08:26.30 |
chrisl | in fapi_ft.c, but it looks like that's not important | 08:27.04 |
| kens: so, in the FAPI case, we're not using the font BBox | 08:30.35 |
kens | OK if I look in the 'Refine FontBBox' then the BBox values look like they are scaled for a 2048x2048 design grid | 08:30.40 |
| chrisl so where do the numbers for the CDevProc come from, direcly from the font ? | 08:31.12 |
| iwe without the 'unifying FontBBox' nonsense in zchar42 ? | 08:31.28 |
chrisl | We "assemble" them in gs_fapi_do_char() in gxfapi.c | 08:32.04 |
kens | If ou are using the numbers directly supplied by the glyph (and not maximising them to the font BBox) then that will work just fine. | 08:32.41 |
chrisl | Specifically, the stuff to do with the font BBox is line ~1534 | 08:32.48 |
kens | Hmm, OK so you are doing the same trickery there | 08:33.13 |
chrisl | But not for CID fonts | 08:33.25 |
kens | Aha, well this is (of course) a CIDFont | 08:33.43 |
| OK so maybe I cna apply the same hack | 08:34.00 |
chrisl | Yes, which is why I keep saying "but not for CID fonts"! | 08:34.02 |
kens | OPK I cna check the font type in zchar42_set_cache and if its 11 then its a CIDFont. Thing is, I would have thought the DynaLab fonts would be CID fotns too. | 08:35.09 |
| Well, I guess I should do this and cluster push | 08:35.21 |
| ANd if its OK I'll make the change and wait for people to shout at me | 08:35.33 |
chrisl | Well, the thing is, what's in FAPI isn't about Dynalab fonts, because Freetype sorts those out - that code is about other buggy fonts..... IIRC, the worst culprit there was a type 1 | 08:36.53 |
kens | I think I'll just have to go with this for now and see what happens. I'm still slightly concerned that the Font BBox is wrong, but I'll live with it for now. | 08:38.01 |
| Of course I should probably have you do this, since its in fonts :-) | 08:38.44 |
tor7 | chrisl: the dynalab code in freetype just sets FT_IS_TRICKY (or some similar) flag you can check, and sadly their check is (was?) incomplete so we have to do another check in mupdf as well | 08:39.49 |
| IIRC freetype doesn't spot dynalab subset fonts | 08:40.21 |
kens | tor7 do we have any examples in teh regression tests ? | 08:40.44 |
tor7 | kens: there should be some in the mupdf set | 08:41.04 |
kens | And those do get run with GS ? | 08:41.20 |
chrisl | tor7: I *think* it's better now - it seems to work for the examples we have. The "tricky" font flag is enough because if you run the hint program, you get the right metrics out. | 08:41.33 |
tor7 | no idea, you'd have to prod robin for details | 08:41.44 |
kens | seems to be needing a lot of help on this one..... | 08:42.01 |
chrisl | I believe we have at least one in the GS test set, because it's behaviour changed when FT's tricky test was changed | 08:42.32 |
kens | OK quick hack for testing, the numbers look plausible, and the output is correct | 08:42.38 |
chrisl | TBH, I think that size/size1 stuff in gs_fapi_prepare_font() is bollocks - which is why we could never understand it! | 08:43.02 |
kens | I suspect you may well be correct.... | 08:43.18 |
| OK *both* my test files work now, previously they were mutually exclusive | 08:43.47 |
| Now for a cluster run, and I'll open a bug report at the same time | 08:44.08 |
| One day I shold look into whether we cna get FAPI to return the metrics stuff, so pdfwrite can do without all this. | 08:45.09 |
chrisl | tor7: actually, now I think about it, the dynalab checking in FT in (currently) moot in the GS, because we (currently) always have bytecode hinting on | 08:56.31 |
| "FT is (currently) moot" | 08:56.49 |
tor7 | chrisl: right, then nevermind what I said :) | 08:56.57 |
| in mupdf we use the dynalab test to turn on hinting at a huge size, so that hinting in practice doesn't affect the glyphs | 08:57.46 |
| hint at 1000pts, render scaled down to the real size | 08:58.17 |
chrisl | tor7: the biggest problem I had was a "tricky" font with a broken (IIRC) font program, and convincing FT to let me render a "notdef" without any hinting at all. | 08:58.42 |
kens | OK so the only file that shows a difference exhibits a preogression :-) | 09:09.58 |
chrisl | kens: the FAPI font BBox is being left in "font units" :-( | 09:11.25 |
kens | Aha, then that's the problem I think. | 09:11.39 |
chrisl | Yes, the problem is that we don't have access to the "units_per_EM" value when we set it | 09:12.15 |
kens | Hmm, well I'll leave that problem for you :-) This one has been hard enough..... | 09:12.47 |
chrisl | kens: fixing the scaling of the font bbox fixes the customer's file | 09:22.55 |
kens | chrisl I thought it would. I think it would be better to fix it that way, if you are reasonably confident that you have a fix. | 09:23.38 |
chrisl | I need to cluster test it, but I think this is the best way | 09:24.05 |
kens | I agree completely, I won't commit my change then, I'll wait. | 09:24.25 |
| Its not been a total loss, I did fix the WMode=1 and no Metrics2 silliness. | 09:25.06 |
chrisl | I still don't know what that size/size1 crap is all about :-( | 09:25.34 |
kens | Me neither, but I wouldn't change it without a reason either | 09:25.57 |
| Hmm, quite a few differences :-( | 09:54.56 |
chrisl | Not as many as I had feared. | 09:56.38 |
| I find it annoying that PS/PDF runs at 300dpi and PCL at 600dpi, it makes it hard to filter out duplicate tests | 09:58.19 |
kens | Hmm yes. FWIW my change only had one diff | 09:58.39 |
| Bug691824.ps is a progression if that comes up | 09:59.11 |
chrisl | It is listed, yes. I'm a little surprised about the PCL diffs, though | 10:00.00 |
kens | Iwas frankly astonished to see those | 10:00.16 |
| But lets see what your bmpcmp throws up | 10:00.34 |
chrisl | That's not good :-( | 10:05.21 |
kens | Nope, not good at all | 10:05.34 |
| I woner if that's a pdfwrite problem or not | 10:06.03 |
| Bug692242.pdf looks wrong before and better now though, possibly its wrong both ways | 10:07.48 |
| No bizareely the partial text is supposed to be there | 10:08.42 |
| THe PCL ones seem to be colour shifts, I can't see how that can be affected by the font change. Is your source up to date ? | 10:10.42 |
chrisl | Yes, I just pulled fresh before doing the cluster run | 10:11.07 |
kens | Odd then. But I now see some of them are the same missing glyphs | 10:11.21 |
| I bet the FontBBox is now small and GS applies it as a clip (Acrobat doesn't) | 10:11.57 |
chrisl | That would be *very* bad :-( | 10:12.37 |
kens | quick way to check is to run one of the simple files through and look at the font BBox | 10:13.08 |
| You might need -dCompressFonts=false | 10:13.21 |
| A lot of the diffs are single pixel shifts in position, or these weird colour changes | 10:14.22 |
chrisl | The pixel shifts are what I expeted | 10:14.49 |
| expected | 10:14.52 |
kens | Yes, I'm happy with those | 10:14.58 |
| I cna't see how changing the Font BBox can cause colour changes | 10:15.17 |
chrisl | I don't understand how the glyph clipping affects *some* sections of text, and not others - seems strange :-( | 10:16.32 |
kens | Hmm, that's really odd. 15-04.bin.pdf at 72 dpi drops a whole line, btu the others (same font) are OK | 10:16.39 |
| wow, 23-02.bin actually looks like an improvement | 10:18.08 |
| There's something really screwy going on with clipping though | 10:19.24 |
| As far as I can tell, the clipping problems only happen if the device is pdfwrite or ps2write | 10:20.48 |
| All the others are colour changes or pixel position shifts | 10:21.02 |
chrisl | It looks that way, yes, which I find really odd :-( | 10:21.21 |
kens | Here's a weird one, c329.bin.pbmraw.600.1 the original looks to be opaque, the current seems to be a mask | 10:22.11 |
| Same with C326 | 10:22.43 |
Amr | Hello, I am facing a problem during building the latest version 1.3 of the mupdf | 10:23.14 |
kens | I don't know which is correct | 10:23.14 |
| chrisl want to send me a copy of the changes you made ? I can have a poke with pdfwrite | 10:24.06 |
Amr | I have downloaded the source from the website, extracted it and opened the Win32 folder to build it on the VS | 10:24.11 |
| but during the build process it gives me 9 successful build and 3 failed | 10:25.09 |
chrisl | kens: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=d44452f3 | 10:26.23 |
kens | OK Let me see. | 10:26.39 |
chrisl | Amr: source for what? GS, GhostPDL, MuPDF?? | 10:26.52 |
kens | He syas MuPDF chrisl | 10:27.00 |
Amr | MuPDF | 10:27.01 |
chrisl | Oh, sorry, missed that - paging tor7, Robin_Watts...... | 10:27.38 |
kens | and paulgardiner | 10:27.45 |
Amr | I am waiting anyone of them to replay | 10:28.40 |
tor7 | Amr: which 3 failed? | 10:28.54 |
| if you do "build all" with the MSVC project it will also try to build several optional targets, | 10:29.21 |
Amr | ok, let me collect the 3 and send to you, just a second | 10:29.37 |
tor7 | like the javascript and curl enabled applications | 10:29.39 |
| if you don't have the binary libraries for those installed in the "thirdparty" folder, you will get some errors | 10:30.03 |
| but the main "mupdf.exe" should still be built just fine | 10:30.14 |
Amr | no no I have the thirdparty lib. and it's already included in the extracted file | 10:30.50 |
Robin_Watts | mupdf-curl, mupdf-v8, mujstest-v8 will fail. | 10:31.24 |
Amr | YESSSS | 10:31.43 |
| Why? | 10:31.47 |
Robin_Watts | Because you haven't installed v8 or libcurl, at a guess :) | 10:32.05 |
| Those are optional things that aren't included in the standard distribution. | 10:32.23 |
tor7 | Amr: we don't include v8 and curl in the standard distribution because a) they're HUGE, and b) they're optional | 10:32.42 |
Robin_Watts | Unless you're specifically looking for http operation, or javascript, you won't need them. | 10:33.11 |
Amr | are they important to the search feature in the MuPDF? | 10:33.25 |
Robin_Watts | no. | 10:33.30 |
Amr | coz I need the newest version as it support searching in Arabic | 10:33.56 |
Robin_Watts | Then you're fine with what you've got. | 10:34.10 |
Amr | but after I build it, some errors appears in Arabic search! | 10:34.23 |
tor7 | Amr: I don't believe we support arabic input in the windows app though :( | 10:34.40 |
Amr | I meant for the Android App | 10:35.00 |
| I can write the Arabic word in a reversed order to find it in the pdf file | 10:35.26 |
tor7 | Amr: right! for android if you find search errors with arabic, we'd really love some help in fixing it. | 10:35.36 |
Amr | I really want to, the MuPDF on the Google play support LTR and RTL search | 10:36.44 |
tor7 | Amr: yeah, I've written some code to reverse the pdf glyphs when extracting the text for search, so that the text should be in logical order. that code may well be buggy, though, it's not extensively tested (and I don't know enough arabic to be able to tell...) | 10:37.10 |
Amr | ok, my question is... why the version I build on my own seems different in the search process? | 10:38.19 |
| it's not similar to the one on the Google play? | 10:38.33 |
kens | chrisl the text isn't even reaching the output PDF file in the case I'm looking at, loosk like its elided before getting there | 10:38.40 |
chrisl | kens: is the page rotated? | 10:38.59 |
kens | chrisl no, its upright | 10:39.06 |
tor7 | I'll leave that question to Robin_Watts | 10:39.06 |
Robin_Watts | Amr: The version on google play is an earlier version. | 10:39.26 |
kens | I'm just about to start digging to find out why pdfwrite thinks it can drop the text. I'm assuming it thinks its clipped | 10:39.30 |
Robin_Watts | It's before tor7's R2L changes I think. | 10:39.40 |
chrisl | kens: I'm looking at t332.bin, which says: "Verify that SetPageRotation does not affect the current clip path", and the glyphs are clipped | 10:40.06 |
kens | I'm using Bug687457.pdf where the bar code vanishes entirely. I've reduced the file to just the barcode | 10:40.43 |
Amr | it was updated in " May 28, 2013" | 10:41.09 |
| isn't this the 1.3 version? | 10:41.20 |
Robin_Watts | Amr: Then, yes. | 10:41.37 |
| It would have been the version current in git at that time. | 10:41.53 |
kens | chrisl I'm seeing that the glyph bbox has ury < lly so pdfwrite drops it | 10:42.47 |
| Hmm FOntBBox is very small | 10:43.28 |
Amr | then why the version on the Google play allows me to find any arabic word I want when I type it on the reversed order but when I build it, it doesn't? | 10:43.38 |
Robin_Watts | Amr: I don't know. | 10:43.54 |
| You could try backtracking to that date and building there? | 10:44.06 |
chrisl | kens: possibly not being scaled with the font? | 10:44.33 |
kens | chrisl the font matrix is multiplied with it, looks OK so far | 10:44.47 |
Amr | this is where I downloaded the src: https://code.google.com/p/mupdf/downloads/list | 10:44.51 |
Robin_Watts | Amr: Oh, sorry, I thought you had checked out from git. | 10:45.13 |
chrisl | kens: what's the font type? | 10:45.32 |
kens | 42 | 10:45.43 |
Amr | no problem | 10:45.47 |
kens | regular TrueType | 10:45.51 |
chrisl | Hmm, can you send me the cut down file? | 10:46.02 |
Amr | that's why I am confused | 10:46.22 |
kens | chrisl one second. | 10:46.29 |
| chrisl on its way. The problem seems to be in gdevpdte.c at about line 422 where it calculates the bbox | 10:47.31 |
Amr | Robin_Watts: any ideas then? | 10:48.10 |
kens | chrisl The FontBBox is 0 0 0.00074 0.00075 | 10:48.44 |
Amr | why that difference between the one on the Google play and the one I build? | 10:49.00 |
kens | WHich sort of looks like 0 0 0.001 0.001 divided by 2 | 10:49.10 |
chrisl | kens: that seems odd :-( | 10:49.17 |
Robin_Watts | Amr: None at all. I am not aware of any changes that have happened between then and now in that area. | 10:49.28 |
kens | chrisl its certainly very small | 10:49.31 |
Robin_Watts | Well, I fixed some reflow stuff, but that shouldn't have made a difference. | 10:49.47 |
| RTL stuff is tor7's baby, not mine, sorry. | 10:49.59 |
Amr | can't you then send me the src you created the version on the Google play? | 10:50.26 |
| if you think that may make a difference | 10:50.47 |
Robin_Watts | Amr: To get that source you want to clone our repo. | 10:51.26 |
| That way you can change to any date you want. | 10:51.33 |
kens | chrisl that looks like a red herring, ignore me | 10:52.00 |
| I'm going to stash and rebuild the old code for comparison | 10:52.28 |
chrisl | kens: If I remove the size/size1 nonsense, the barcode appears....... | 10:52.33 |
kens | gibbers | 10:52.42 |
Amr | you think if I cloned it then it will be different from the one on your website? | 10:54.03 |
Robin_Watts | Amr: The one on the website is a snapshot from the git at a given time. | 10:54.47 |
| The git will enable you to move back and forward in history, getting to any of our snapshots, or when we built for the app store etc. | 10:55.12 |
chrisl | kens: it also looks like the PXL test I was looking at is "correct" without that nonsense | 10:55.20 |
Robin_Watts | If you can find when we broke it, it makes fixing it easier :) | 10:55.26 |
kens | Oh dear, maybe we have found a good reson to kill it | 10:55.35 |
| chrisl without the changes the font BBox is 2048 times bigger, or thereabouts, which explains the problem | 10:56.19 |
chrisl | I'm wondering if it was a hack because whoever did it didn't understand the units the BBox was being returned | 10:56.30 |
kens | chrisl I suspect you may be correct, an early and misguided attempt to fix the same problem. | 10:56.50 |
Amr | good, and if I could I would be able to give you a final solution to the Arabic Search to make it works 100% | 10:56.53 |
Robin_Watts | Amr: That would be much appreciated. | 10:57.09 |
kens | chrisl I guess the obvious thing is a cluster run with that removed as well | 10:57.12 |
chrisl | kens: of course, I haven't checked that the customer files still works like that, so...... | 10:57.28 |
Amr | I just need some help from you to be sure that I am cloning it in the right way | 10:58.17 |
kens | chrisl I guess that's worth checking, but japan1.ps didn't show up as different either, and tis a similar file. | 10:58.47 |
Amr | can you tell me just quick steps to clone it? | 10:58.56 |
chrisl | kens: customer file does still work with the size/size1 crud removed | 10:59.16 |
kens | chrisl I'm more concenred that removing the code will break something else | 10:59.23 |
| But that's good news at least ;-) | 10:59.32 |
chrisl | It's running on the cluster now. | 10:59.41 |
kens | OK then I will have an early lunch | 10:59.50 |
| back in a bit | 10:59.59 |
chrisl | Yeh, I need to go buy some lunch - my fridge it MPT :-( | 11:00.15 |
tor7 | Amr: git clone --recursive git://git.ghostscript.com/mupdf.git | 11:00.48 |
Amr | tro7: I should write this command in the git bash right? | 11:03.50 |
tor7 | Amr: yes. | 11:05.07 |
Amr | ok, I did but it told me that destination path "mupdf" already exists, how to remove that to be able to clone it again? | 11:06.28 |
Robin_Watts | Amr: You already have a directory called mupdf there, right? | 11:08.35 |
| Either delete that first, or... | 11:08.51 |
Amr | yes | 11:08.51 |
Robin_Watts | git clone --recursive git://git.ghostscript.com/mupdf.git mupdf.git | 11:09.01 |
| That will check out the git thing into mupdf.git | 11:09.15 |
| s/check out/clone/ | 11:09.24 |
kens | chrisl that's a much happier looking set of diffs. I don't understand the PXL ones but I'm betting they are colour shifts | 11:14.32 |
Amr | Okay, i deleted it and I am cloning it right now | 11:14.48 |
| okay, I have cloned it | 11:24.16 |
Amr_ | Robin_Watts: now I am going to open the Win32 folder and build the project | 11:29.22 |
Robin_Watts | Amr_: That will build you the latest version. | 11:29.34 |
| You probably want to go back to 13 May first. | 11:29.44 |
Amr_ | how? | 11:29.54 |
Robin_Watts | sorry, May 28th. | 11:30.03 |
| git checkout 6000538 | 11:30.35 |
Amr_ | how to go back to May 28th? | 11:30.35 |
| k | 11:30.40 |
Robin_Watts | git submodule update --init | 11:30.51 |
| Then you should be back pretty much exactly with the source I built the google play release with. | 11:31.20 |
Amr_ | you sure from the command: git checkout 6000538? | 11:32.23 |
Robin_Watts | Yes. | 11:32.40 |
| That, then git submodule update --init | 11:32.51 |
Amr_ | it's giving me after I wrote the git checkout 6000538 this error: fatal: not a git repository (or any of the parent directories): .git | 11:34.33 |
Robin_Watts | cd mupdf.git | 11:35.03 |
Amr_ | ok I wrote the two commands | 11:36.37 |
| now I open the Win32 and build it from the VS? | 11:36.55 |
kens | chrisl bug689677.xl is a progression, text that was missing (and is present with teh PCL rendering to display) now renders properly. 16-05.ps was wrong before and wrong now i a subtly different way, I don't propose to worry about it. C311.bin looks closer now to the PCL display device result, IMO teh previous one was too skinny. C318 and C319 look like progressions, I think the text was previously missing and now is present. Same for C329 | 11:40.40 |
Robin_Watts | Amr_: Yes. | 11:41.27 |
Amr_ | ok, I build it on VS with 7 succeeded, 3 failed, 0 up-to-date, 0 skipped | 11:45.14 |
| now I am going to open Cygwin and use ndk to complete the build | 11:45.37 |
Robin_Watts | ok. | 11:46.01 |
| Well, cygwin + ndk to do the next stage of the build. | 11:46.36 |
chrisl | kens: that looks pretty convincing to me! | 11:46.45 |
kens | chrisl ignore bug687603.ps its good enough, may even be better now, bug691824.ps is a progression, japan-.ps is close enough | 11:46.49 |
Robin_Watts | Then you use the sdk to complete it. | 11:46.52 |
kens | chrisl the only ones that puzzle me are the colour changes | 11:47.15 |
chrisl | Yes, those are bemusing..... | 11:47.57 |
Robin_Watts | kens: random thought... are you up to date? | 11:48.11 |
kens | Robin_Watts : its chris' dump | 11:48.19 |
| chrisl looking at PLTT7SCC.BIN the new result looks more correct than the reference | 11:48.39 |
chrisl | I pulled the code about an hour ago | 11:48.50 |
kens | The text is supposed to be darker | 11:48.54 |
| I think the same is true of PWEP5SC1.BIN | 11:51.48 |
Amr_ | Okay Robin_Watts: the build is complete, now I am going to import it to Eclipse and see if it's working like the version on the Google play or not | 11:52.26 |
Robin_Watts | cool. | 11:52.39 |
kens | chrisl I think we should go ahead. The PCL colour shifts seem to be negligible or arguably progressions, and tehre are a fair number of genuine progressions in there. The only diffs I can't be sure of seem to be in rasterops and they don't work right anyway | 11:56.20 |
chrisl | kens: okay, I'm going to finish lunch, then compose a suitable commit message, then I'll push | 11:57.19 |
kens | OK when you've done that I'll tell teh customer. | 11:57.32 |
| BTW there's one change that seems to be a major progression with teh colour changes, 23-02.bin | 11:58.01 |
| It looks like the 'halftone dots' are really text and they are now much biigger, and therefore more correct | 11:58.35 |
Amr_ | Robin_Watts: this is weird, it works but not the same way of the version on google play | 11:59.24 |
| it's not accurate like the google play version | 11:59.44 |
Robin_Watts | Amr_: Well, at this stage I think you need to talk to tor7. You need to describe exactly how he can reproduce the problems (probably an example file, plus step by step instructions of what he should do to reproduce the issue). | 12:01.11 |
| BUT... you may need to wait for tor7 to have a suitable time in his schedule to fit this in. | 12:01.30 |
Amr_ | I don't need to write the Arabic word in a reversed order, in this version I can write it without reversing it, but when I hit search, it finds the words but doesn't highlight them correctly, there is shifting in the highlighting | 12:02.21 |
| mmm... ok :) | 12:02.28 |
kens | chrisl I've eyeballed all the diffs now, and checked them against the originals where I needed to. IMO your change is a well worthwhile improvement, quite apart from the customer bug. A good number of files are improved, and the only ones I cannot be sure of are either terribly minor, or rasterops. And as a bonus you get rid of that nasty hacky code we couldn't understand. | 12:02.43 |
Robin_Watts | wonders why his new Type3 font -> SVG code isn't producing any output, then realises that he's not written code to convert imagemasks to svg yet. | 12:02.51 |
tor7 | Amr_: you can try selecting text to copy and seeing if the selected text matches what you paste | 12:04.56 |
Amr_ | tro7: ok I selected text and copied it to the search bar but another text was copied not what I selected, I tried this several times but the same results and when I click search on what was copied, it doesn't find anything | 12:09.44 |
| so, it's not matching what I paste | 12:11.35 |
paulgardiner | Amr_: Did you tap the "tick" button after sellecting text? | 12:13.30 |
Amr | what is the "tick" button? | 12:25.02 |
| paulgardiner: what is the tick button? | 12:27.23 |
paulgardiner | The rightmost button on the top bar. It appears when you tap the copy-to-clipboard button. If that makes no sense, I may have misunderstood what you are attempting to do. | 12:28.34 |
Amr | ok, yes I do | 12:29.46 |
chrisl | kens: pushed | 12:30.45 |
| kens: if you could pull the code, and double check the customer's file, I'd appreciate it. | 12:32.23 |
paulgardiner | Amr: if you then paste what's in the clipboard into notepad (say), does it corespond to the text you selected from the document page? | 12:33.39 |
Amr | paulgardiner: yes i do | 12:33.46 |
| no it doesn't match | 12:34.35 |
| paulgardiner: I just copied it to my memo app on the android device and it didn't match what I selected | 12:35.24 |
paulgardiner | Is it another part of the document, or just random garbage? | 12:36.01 |
| Or some text you may have selected earlier using a different app on the same device? | 12:36.34 |
kens | chrisl sorry was out shopping, will do pull and check now | 12:37.07 |
| I'll also double check withteh original file | 12:37.33 |
Amr | part of the document is correct and the rest is Arabic words but was not selected | 12:39.33 |
kens | chrisl the cut down file looks fine, the customer's original is certainly very much improved. There is a slight vertical difference when compared with Distiller's output, but if they complain about that it'll be my problem I think (I hope they don't). | 12:42.37 |
chrisl | kens: thanks | 12:43.44 |
kens | Thanks for sorting it out for me ;-) | 12:44.00 |
paulgardiner | Amr: okay, that's not too surprising. I don't think we expect that to be fully working yet. | 12:45.02 |
chrisl | It's nice to get rid of another piece of "WTF code" in FAPI! | 12:45.20 |
kens | Absolutely :-) | 12:46.06 |
Amr | paulgardiner: but how the Arabic search is working on the google play version? :D although it's the same that I have downloaded its src | 12:46.47 |
| the version of google play is perfect in the Arabic search, if I could get its src correctly, I can solve the Arabic problem for you forever | 12:47.55 |
paulgardiner | Are you sure you have checked out your git working copy to match the date of play version? And you have no local source changes? | 12:49.16 |
kens | And done a clean rebuild.... | 12:49.29 |
Amr | Yes I am 100% sure, I made it step by step with Robin_Watt to ensure that I am getting it right | 12:50.20 |
paulgardiner | Ah yes. Good call kens. If using eclipse you need to clean the java build too. If not using eclipse, there could be a similar requirement, but I'm unsure what. | 12:51.18 |
kens | has been bitten by that one before.... | 12:51.43 |
Amr | I am using Eclipse, how to clean the java build then? | 12:52.00 |
| you mean just choose clean from the project tab in Eclipse? | 12:52.49 |
paulgardiner | Yep | 12:54.09 |
Amr | ok, I did and ran it again but it showed me the same problem which it's not working the same way of the version on google play | 12:56.08 |
| paulgardiner, I noticed something now, the statement I copy and paste to the clipboard, it pasted the text but with missing middle words | 12:58.18 |
| the last word is always copied | 12:58.38 |
| but some middle words don't | 12:58.48 |
paulgardiner | You could try checking out from git vesions from a week either side of the current date to see if you can get behaviour to match the google play version that way. | 13:00.24 |
Amr | this is also what I did with Robin_Watt | 13:01.08 |
paulgardiner | Sorry, I think I've run out of ideas too. | 13:01.41 |
Amr | can't you build it and open an Arabic file? | 13:02.59 |
Robin_Watts | Amr: As I said earlier, you need to give us clear instructions. | 13:07.04 |
| Give us an arabic file that shows the problem. | 13:07.13 |
| Tell us what to search for or to attempt to cut/paste. | 13:07.25 |
| Given that none of us speaks arabic, you need to be very clear in your explainations. | 13:07.43 |
Amr | ok, i will upload that file and send you the link | 13:07.55 |
Robin_Watts | Amr: Please use a bug. | 13:08.17 |
| Go to bugs.ghostscript.com | 13:08.24 |
Amr | ok, sorry | 13:08.28 |
| Robin_Watt: http://bugs.ghostscript.com/show_bug.cgi?id=694701 | 13:33.37 |
Robin_Watts | Todays WTF from the mupdf source: if (pix->colorspace != fz_device_gray(ctx) || pix->colorspace != fz_device_rgb(ctx)) | 13:33.49 |
| Amr: Thanks. | 13:34.28 |
| oh, buggering SVG strikes again. | 13:55.29 |
| In order to do an imagemask, I need to send <mask id="something"><image ...></mask> then I need to fill the mask... <rect ... mask=url(#something)/> | 14:02.44 |
| BUT... if I'm in the middle of defining a symbol (say for a type 3 font), the definition of "something" is ignored, so nothing gets drawn :( | 14:03.12 |
tor7 | Robin_Watts: oh... | 14:04.45 |
| is the order of symbols relevant in svg? | 14:05.14 |
Robin_Watts | I think I need to define before use. | 14:05.32 |
| Let me test that. | 14:05.47 |
tor7 | I think you're just going to have to bite the bullet and do buffering of the current item you're generating | 14:05.47 |
| so that you can output dependent items beforehand | 14:06.08 |
Robin_Watts | Maybe order isn't important. | 14:06.40 |
tor7 | but if the order doesn't matter, you could postpone outputting the image mask until after the type3 glyph symbol | 14:06.51 |
Robin_Watts | tor7: Yeah. That would enable me to keep just generating as I go, with a 'definition' buffer that would get periodically flushed. | 14:08.18 |
| I'll give that a go. Thanks. | 14:08.59 |
mvrhel_laptop | good morning | 15:00.29 |
kens | Hi Michael | 15:00.34 |
mvrhel_laptop | morning kens | 15:00.42 |
ray_laptop | morning, all | 15:00.58 |
Robin_Watts | morning | 15:00.59 |
kens | Hi also ray_laptop | 15:01.04 |
henrys | mupdf meeting time. | 15:01.11 |
tor7 | whoa. already? day's just got started :( | 15:01.33 |
henrys | should we just have 1 meeting now where everyone goes to both? | 15:02.05 |
kens | Please no :-( | 15:02.17 |
Robin_Watts | We should have 2 meetings, and everyone should go to both. We'll just do them at the same time. | 15:02.55 |
mvrhel_laptop | just merge them all at 9:00 am PDT? | 15:02.56 |
Robin_Watts | Should we have a meeting about the meetings? | 15:03.33 |
henrys | mvrhel_laptop: yes that was my thinking | 15:03.41 |
mvrhel_laptop | henrys: that would be nice for me. 8:00 has gotten tricky with school started | 15:04.03 |
| any other opinions? | 15:04.37 |
henrys | kens doesn't seem crazy about the idea. | 15:04.38 |
tor7 | start at 8:30 so ken doesn't have to stay later, in case we run late? | 15:04.45 |
paulgardiner | I'll need to reorganise things to stay much past 5pm on a Tues | 15:04.46 |
mvrhel_laptop | he still only goes to one meeting | 15:04.47 |
kens | yes but it takes twice as long that way | 15:05.01 |
Robin_Watts | Merging the 2 meetings is likely to make the meeting go longer, which is a problem for ken | 15:05.05 |
mvrhel_laptop | oh I see | 15:05.11 |
kens | and 50% of it I have nothing to contribute | 15:05.11 |
mvrhel_laptop | I could do 8:30, but I might be a few minutes late occasionally | 15:05.37 |
Robin_Watts | Would it make sense to move the gs meeting half hour earlier, then have the mupdf one after that? | 15:05.41 |
mvrhel_laptop | that would be a problem for paul right? | 15:06.01 |
ray_laptop | 8:30 _should_ be OK for me. | 15:06.04 |
Robin_Watts | no, that would be bad for paul and tor. | 15:06.05 |
kens | meetings on different days ? | 15:06.22 |
Robin_Watts | I believe there are other meetings on other days already. | 15:06.57 |
henrys | kens:I actually wanted to do say 1 45 minute meeting. | 15:07.01 |
paulgardiner | Tues and Thurs are the only awkward days to staying past 5 | 15:07.08 |
| ... for me I mean | 15:07.16 |
kens | henrys it 'might' be possible, Melanie has changed horse share, so Tuesdays might be a bit more flexible, but I don't know yet | 15:07.53 |
henrys | I think ray_laptop and I get up early not sure about mvrhel_laptop but if we went to 7 Pacific would that work? | 15:09.13 |
mvrhel_laptop | from 7 to 7:45? | 15:09.50 |
kens | Anything that doesn't run past 17:30 UK time is fione by me in any event | 15:09.51 |
ray_laptop | I get up early (6:00am Pacific) most days, but I have to take the kids to school at ~7:15 -- back home by about 7:30 | 15:10.26 |
henrys | mvrhel_laptop: yes I thought that would not interfere with the school run | 15:10.28 |
mvrhel_laptop | actually 7:30 to 8:15 would be about perfect. | 15:10.52 |
| which lines up with ray_laptop | 15:11.13 |
ray_laptop | I have one school run at 7:15am, return 7:30 and the other at 8:15 return about 8:40 | 15:11.31 |
mvrhel_laptop | mine is the same | 15:11.39 |
ray_laptop | but on Tuesdays, my wife take the late run, so I'm good to go after 7:30 | 15:12.22 |
kens | Current time is 08:15 there ? | 15:13.10 |
henrys | kens: yes | 15:13.19 |
| 9:15 for me but I don't want to complicate the issue. | 15:13.38 |
kens | Fine by me, if its OK with ray and michael | 15:13.39 |
henrys | I figure earlier is better for all UK folks | 15:13.58 |
kens | henrys just checking that PDT was what I thought it was ;-) | 15:13.59 |
Robin_Watts | Anytime is fine with me. | 15:14.30 |
| Have we now moved to be bang in the middle of tor7's dinner time? | 15:14.53 |
henrys | okay 15 minutes to do that actually I thought it would be worse | 15:14.58 |
ray_laptop | so, it's 8:15. That means the meeting is now over ? ;-) | 15:15.06 |
Robin_Watts | http://ghostscript.com/~robin/out4.svg | 15:16.02 |
tor7 | Robin_Watts: I've already scheduled late dinners on tuesdays, moving meetings to an earlier time slot is only more convenient | 15:16.12 |
henrys | tor7:we have on the agenda cmyk output and some customer interest, how far off is that? | 15:16.15 |
kens | Robin_Watts : that looks quite nice, and reasonably quick to render | 15:16.26 |
Robin_Watts | kens: Only the (C) symbol is type 3. | 15:16.42 |
tor7 | not any slower than the stuff with path based fonts | 15:16.55 |
kens | It does look a bit rough | 15:16.55 |
| The copyright symbol that is | 15:17.04 |
Robin_Watts | kens: It's an imagemask. Looks better in chrome than in IE. | 15:17.14 |
kens | some odd baseline stuff going on with the text too | 15:17.26 |
| "This thesis..." | 15:17.33 |
Robin_Watts | kens: yeah, I think the maths is right, the svg engines just aren't perfect. | 15:17.53 |
tor7 | The (C) symbol looks like it's been rendered with nearest neighbor sampling on firefox | 15:17.54 |
kens | Robin_Watts : I guessed it might be that | 15:18.04 |
| Let me try zooming in | 15:18.12 |
henrys | Robin_Watts:maybe the spacing is a bit off - try highlighting Atomistic - but anyway nice! | 15:18.18 |
Robin_Watts | kens: Let me know if you figure out how :) | 15:18.25 |
kens | ctrl+ | 15:18.35 |
| It looks better that way | 15:18.45 |
tor7 | Robin_Watts: the baseline stuff, could that be related to the shifting you do to reposition the glyphs in a positive bbox? | 15:18.45 |
Robin_Watts | henrys: The text isn't text. | 15:18.58 |
| It's paths, with 'alpha =0' text overprinted so you can select it. | 15:19.14 |
| hence the boxes for the highlight are calculated from glyphs in the wrong font. | 15:19.26 |
kens | At maximum zoom its 'almost' all right, and the copyright is much nicer | 15:19.39 |
Robin_Watts | hence the wierd highlight stuff. | 15:19.42 |
| I claim that I'm doing it right, and the renderer is getting it wrong, so I propose not to worry :) | 15:20.01 |
kens | Robin_Watts : I strongly suspect you are correct | 15:20.22 |
Robin_Watts | tor7: It looks much better now than it did before I was doing that shifting. | 15:20.22 |
kens | THe fact that it looks better when zoomed makes me suspect the rendering engine anyway | 15:20.52 |
Robin_Watts | henrys: cmyk output... | 15:20.54 |
tor7 | Robin_Watts: could you set the shifting at a fixed (per font) value to see if it improves? | 15:21.06 |
Robin_Watts | we can do cheap and crap cmyk output by converting from rgb -> cmyk at the end. | 15:21.12 |
tor7 | improves the baseline even-ness that is | 15:21.13 |
henrys | Robin_Watts: if you copy paste it the spaces disappear entirely. | 15:21.26 |
Robin_Watts | henrys: right. There are no spaces in the original PDF. | 15:21.48 |
henrys | Robin_Watts: so that would have to be done heuristically if at all. | 15:22.06 |
kens | Chrome is better right from the off with that file | 15:22.08 |
Robin_Watts | henrys: Indeed. | 15:22.14 |
kens | With Chrome some levels of zoom are good, some are nasty | 15:22.46 |
Robin_Watts | If we want to do 'proper' cmyk, then we'd need to do 'proper' color management, right? | 15:22.59 |
henrys | Robin_Watts: it's an agenda item so I thought cmyk was a "defined" project. | 15:23.13 |
Robin_Watts | I was planning to ask at the meeting if I should go ahead and mail marti about the lcms2 threading problems and whether he'd be up for paid work to fix it. | 15:23.38 |
tor7 | we discussed rendering to (our existing) devicecmyk and finding the bugs and holes in the path plottingc | 15:23.48 |
Robin_Watts | I believe Michael was thinking that he would be seeing him in November and now he's not going to, | 15:24.06 |
tor7 | just to see that we can do non-rgb and non-gray rendering with mupdf | 15:24.09 |
Robin_Watts | tor7: Ah, right. | 15:24.15 |
| Well, I can certainly look into that next if we want. | 15:24.29 |
mvrhel_laptop | Robin_Watts: is he aware of the issue | 15:24.30 |
| ? | 15:24.33 |
ray_laptop | Robin_Watts: and handle proper overprint | 15:24.34 |
Robin_Watts | mvrhel_laptop: Yes, he's aware of the issue. | 15:24.43 |
tor7 | ray_laptop: overprint? mwuahaaa :) | 15:24.52 |
Robin_Watts | He wasn't keen on fixing it (he just planned to document it as a known problem). | 15:25.04 |
mvrhel_laptop | I see | 15:25.12 |
Robin_Watts | I'd like to suggest a 'neat' way of fixing it that won't break compatability with existing apps. | 15:25.24 |
| I spent some time over the weekend playing with revising the headers etc. | 15:25.41 |
henrys | so what exactly is the cmyk output item on the agenda and why is it assigned to tor7 if it require heavy handed color management. I was under the impression something simpler was in the works. | 15:26.11 |
mvrhel_laptop | so are we thinking of mupdf doing just cmyk or doing a full separation output (spots) also? | 15:26.33 |
kens | Robin_Watts : if paying Marti will help get the library fixed to the poitn we need, tehn it sounds like a good approach to me. We do need LCMS I think | 15:26.35 |
ray_laptop | cmyk doesn't require color management, does it ? | 15:26.49 |
Robin_Watts | henrys: As tor7 said earlier, I think the idea is just to try rendering to cmyk and fix the problems we meet. | 15:26.54 |
| I think either tor7 or I could handle that task. | 15:27.22 |
| and I'm 'between tasks' at the moment. | 15:28.05 |
henrys | tor7:okay so if you can bump the priority of that a bit. | 15:28.06 |
ray_laptop | one area that's a bit complex is using the correct blending colorspace with transparency | 15:28.24 |
Robin_Watts | ray_laptop: We currently treat all blending as rgb. | 15:28.44 |
ray_laptop | but mvrhel_laptop would know how much difference that makes | 15:28.54 |
Robin_Watts | I suspect that for the first version we would continue to do so. | 15:28.57 |
ray_laptop | Robin_Watts: so does cust 532, and it passes their QA | 15:29.14 |
mvrhel_laptop | yes. I think we keep trans blending in rgb | 15:29.29 |
| for the first phase of this | 15:29.36 |
henrys | paulgardiner: so I'll officially assign the MS office research project to you. | 15:29.41 |
ray_laptop | but the overprint did come up with them, which mvrhel_laptop fixed with the SimulateOverprint | 15:30.06 |
paulgardiner | henrys: sure. How does it compare in priority with the iOS work? Still have a fair bit to do on that. | 15:30.35 |
henrys | paulgardiner: I think first step is seeing what is available open source wise. | 15:30.36 |
mvrhel_laptop | so this is a current customer that wants cmyk from mupdf? | 15:31.03 |
ray_laptop | so if you are looking at a customer quality cmyk mupdf, I think overprint is important | 15:31.05 |
henrys | when you need a break from iOS do some of that. | 15:31.06 |
Robin_Watts | henrys: You'd pointed to apache POI as a possible starting point. It's got a nice license etc, but it's entirely java. | 15:31.29 |
paulgardiner | henrys: okay. Sounds good to me | 15:31.35 |
Robin_Watts | Are you thinking that we could accept a java based solution? Or that it'd need to be ported down to C or something? | 15:31.54 |
ray_laptop | Robin_Watts: so we just drop in a java vm ? | 15:31.57 |
Robin_Watts | ray_laptop: 'just'. | 15:32.13 |
ray_laptop | forgot the ;-) | 15:32.22 |
henrys | Robin_Watts: I'm thinking you're stuck with Java yes, but I could be wrong. | 15:32.30 |
tor7 | henrys: are there any more details on the MS office project? | 15:32.37 |
paulgardiner | henrys: re the iOS work, v8 looks problematic on iOS, but v7.1 gives access to the javascriptcore engine | 15:33.03 |
henrys | tor7:print and view xl, pp and office | 15:33.36 |
| no writing | 15:33.44 |
ray_laptop | did we determine what version office files we are looking to supporrt -- just the modern XML style stuff ? | 15:33.55 |
henrys | s/office/word | 15:34.00 |
paulgardiner | Using that engine looks like a good option, but will require a new js-wiring-layer | 15:34.05 |
henrys | docx no legacy stuff | 15:34.07 |
ray_laptop | or the old stuff, too | 15:34.09 |
Robin_Watts | paulgardiner: For android, it could possibly call the JNI stuff I've been doing. | 15:34.28 |
tor7 | apache POI is written in java | 15:34.33 |
ray_laptop | henrys: I thought that was what was said at the staff meeting -- just double checking | 15:34.43 |
Robin_Watts | For non android platforms... god knows. | 15:34.54 |
| actually, the JNI should be the same, right? | 15:35.05 |
| ray_laptop, henrys: Apache POI does both docx and legacy. | 15:35.20 |
ray_laptop | Robin_Watts: I would think so | 15:35.22 |
Robin_Watts | For excel sheets, it puts them both under a common interface. | 15:35.50 |
henrys | Robin_Watts: yes I know I was repeating the customer request | 15:35.53 |
Robin_Watts | For word docs, separate interfaces currently. | 15:36.08 |
ray_laptop | how's the "support" on the POI stuff ? Is there activity ? | 15:36.18 |
paulgardiner | Robin_Watts: so are you saying if the Android app were updated to use your new interface, then we could patch POI underneath it? | 15:36.24 |
Robin_Watts | We need to be a little careful with the POI stuff as the word support has no lead programmer anymore. | 15:36.37 |
ray_laptop | underneath or on top of ? | 15:36.42 |
tor7 | for word we'd really need to match the text layout (or at least line breaking) which is a bit more involved than just getting the text extracted | 15:36.46 |
| not sure how far POI gets us there | 15:37.04 |
henrys | paulgardiner: sigh about the javascript engine. | 15:37.05 |
Robin_Watts | paulgardiner: I'm saying that we presumably want to write some java code that calls POI to read files, and call the fz_device layer to convert into mupdf format. | 15:37.37 |
henrys | tor7:yeah that was just something I looked at briefly | 15:37.48 |
| I liked the license ;-) | 15:37.56 |
paulgardiner | henrys: possibly it's a good thing, other than the effort involved. It would be good to demonstrate that we can support more than one engine | 15:38.08 |
henrys | paulgardiner: true. | 15:38.18 |
Robin_Watts | I thought that old versions of word contained the line breaking information internally at least. | 15:38.34 |
| dunno about the new stuff. | 15:38.56 |
henrys | if we end up with office in java not sure about iOS ⦠I thought there were noises about an oracle port but I don't know the state of that. | 15:39.01 |
Robin_Watts | So 'dumb' viewers were a lot easier. | 15:39.12 |
tor7 | Robin_Watts: I know that the pagination changes if you change printer in the page setup... if the printers have different DPI | 15:39.28 |
paulgardiner | I may not be understanding the main goal of the office work. If we rely on java then we've extended the android app, but not the library. | 15:39.38 |
tor7 | or line breaking as it were | 15:39.39 |
henrys | I think we might have an overly poisonous view of office because of history. It now is an open spec. | 15:40.02 |
tor7 | but if as you say the line breaking was in the file, then it'd make things a lot easier | 15:40.03 |
Robin_Watts | paulgardiner: The idea is so that we can sell "a solution" to customers. | 15:40.21 |
| If we rely on a java based solution to read office docs, then we end up selling "a mixed java and native solution" to customers that need to have a JVM as well. | 15:41.02 |
paulgardiner | But presumably adding office support to the C library, in the same way as XPS, would be the preference? | 15:41.14 |
Robin_Watts | paulgardiner: That would be ideal. | 15:41.24 |
| but Apache POI doesn't get us to that easily. | 15:41.33 |
| If you can find an alternative solution that's C based, that would be even better. | 15:41.44 |
tor7 | I'd suggest not going down the path of adding even more features that the android app can do that none of our other platforms have anything to show for | 15:42.08 |
paulgardiner | If restricting to docx, I wonder how hard it is to do our own thing. | 15:42.11 |
henrys | Robin_Watts: I guess I don't understand something aren't we "selling" java code now? | 15:42.17 |
tor7 | even Robin's JNI bindings are android specific, and won't work with desktop Java IIRC | 15:42.30 |
Robin_Watts | henrys: Are we? | 15:42.34 |
| tor7: I don't believe they are android specific. | 15:42.42 |
| or at least, if they are, they needn't be. | 15:42.53 |
tor7 | the android.Bitmap and Rect classes you use in the bindings? | 15:42.57 |
chrisl | Why not look at the spec, first - it might be fairly easy to implement | 15:42.58 |
ray_laptop | we wouldn't consider java to C from the POI, would we ? | 15:43.04 |
Robin_Watts | tor7: Right, so those small bits need to be unpicked. | 15:43.15 |
| The rect class is trivial. | 15:43.35 |
| The bitmap class needn't be hard. | 15:43.41 |
tor7 | please, no java dependencies in the core library | 15:43.46 |
paulgardiner | chrisl: yeah, at least taking a look would make sense | 15:43.48 |
Robin_Watts | henrys: In what way are we selling java code now? | 15:44.05 |
henrys | I was hoping POI would end up being like a third party - where we could pull fixes from them but maybe that is not possiblele | 15:44.07 |
tor7 | Robin_Watts: yeah. I just made a mental note when I saw them that there were android specific bits to it. | 15:44.08 |
henrys | Robin_Watts: I though much of the form stuff was done in java | 15:44.22 |
Robin_Watts | henrys: java != javascript. | 15:44.35 |
chrisl | paulgardiner: it would be nice (but probably hopeless) to hope the office XML bares some relation to XPS...... | 15:44.48 |
Robin_Watts | The two are completely unrelated, except for the name. | 15:44.50 |
tor7 | chrisl: I suspect the only thing in common is wrapping it up in a zip file :) | 15:45.10 |
henrys | I must be going crazy I thought I saw java changes from paulgardiner in commit messages. | 15:45.18 |
paulgardiner | henrys: the form stuff relies on javascript for full functionality, but works to some extent without it. | 15:45.26 |
chrisl | tor7: you are probably right | 15:45.27 |
henrys | I understand java is not javascript | 15:45.29 |
Robin_Watts | henrys: The android app is written in java. | 15:45.39 |
| because all apps on android are at least superficially java. | 15:45.55 |
paulgardiner | henrys: in fact, AFAIKT, adobe reader on android supports forms without javascript | 15:45.57 |
Robin_Watts | but we try to keep the java side of things as small as possible, so the 'smarts' are all in the lib. | 15:46.42 |
| In general the java side is 'just' UI (as far as possible) | 15:46.56 |
tor7 | IMO we've put too many smarts in the C side of the java bindings in the android app, which is why I've been pushing Robin to write the new JNI bindings. | 15:47.41 |
paulgardiner | yeah, the java is generally UI (and the bits that need translating to Objective C for iOS) | 15:47.47 |
Robin_Watts | Yeah, the current java bindings in IOS were done to be 'just enough' for what we needed for the app. Doing proper generic bindings would make it a lot nicer. | 15:49.02 |
henrys | Robin_Watts:okay but I'm sure a customer is fiddling with UI doing something in Java and selling the product the magazine vendors for example. They distribute a VM? | 15:49.17 |
Robin_Watts | henrys: On what platform? | 15:49.35 |
henrys | android | 15:49.48 |
Robin_Watts | On Android, ALL apps are written in java (at least superficially). Android comes with the Dalvik VM as it's core. | 15:50.00 |
henrys | We would not support a platform that doesn't have a vm | 15:50.16 |
Robin_Watts | So on Android, we could probably do a Apache POI based solution. | 15:50.21 |
| On iOS... no chance. | 15:50.29 |
henrys | Robin_Watts: not sure about that Oracle is working on a port | 15:50.45 |
kens | : But will Apple approve it ? | 15:50.58 |
Robin_Watts | Oracle can port what they want, but it's Apples ball, and if they don't want to let Oracle play then Oracle can go and stand in the corner with Macromedia. | 15:51.30 |
henrys | and there is always java 2 objc translator ;-) | 15:51.39 |
Robin_Watts | s/Macromedia/Adobe/ | 15:51.43 |
ray_laptop | on iOS, there is j2objc | 15:51.57 |
henrys | Robin_Watts: I think java might be too large for even apple to ignore but we'll see. | 15:52.25 |
ray_laptop | types to slowly | 15:52.26 |
Robin_Watts | The java thing is NOT a showstopper, cos we can probably work around it on pretty much any platform other than iOS, but, it *IS* a big shift in the way we work. | 15:52.44 |
| henrys: people said that about flash. | 15:52.59 |
| Apple REALLY don't want to let people run unapproved apps. And the moment a jvm gets onto the platform, that train has sailed. | 15:53.31 |
paulgardiner | On the other hand, if there is another opensource office implementation out there written in C then that has to be far better for us | 15:53.41 |
Robin_Watts | paulgardiner: Indeed. | 15:53.54 |
henrys | paulgardiner: open office is java I think the new libre stuff is C++ | 15:54.22 |
Robin_Watts | Apache POI made reference to the fact that some of it is "XXXXXX converted to java". | 15:54.35 |
| so maybe we could look at XXXXXXX. | 15:54.43 |
tor7 | Robin_Watts: not to mention the memory hogness of a java VM for each app | 15:55.03 |
| on android, the JVM overhead is at least shared between apps | 15:55.16 |
Robin_Watts | libreoffice was (at the time of the split) just openoffice with the office import filters included by default. | 15:55.18 |
paulgardiner | XXXXXXX: A language I've always wanted to learn | 15:55.21 |
tor7 | abiword must have a doc importer | 15:55.36 |
Robin_Watts | where XXXXXXXX = some program in C who's name I forget. | 15:55.49 |
henrys | anyway we are coming up on the gs meeting. Are there other mupdf issues? | 15:55.50 |
Robin_Watts | henrys: Are you OK with me mailing marti about the possibility of him working on lcms for us? | 15:56.09 |
chrisl | tor7: abiword is GPL | 15:56.18 |
henrys | Robin_Watts: yes that is fine. | 15:56.21 |
Robin_Watts | henrys: thanks. | 15:56.28 |
tor7 | chrisl: right. but it's in C (or is it C++?) | 15:57.04 |
Robin_Watts | tor7: but it's GPL, so no use to us at all, right? | 15:57.23 |
tor7 | Robin_Watts: pretty much, yeah :( | 15:57.38 |
henrys | tor7:we could offer them money to go dual if the code were really good. | 15:58.41 |
Robin_Watts | henrys: The odds of that working halve with every contributor they've had... | 15:59.07 |
tor7 | henrys: too many contributors *may* be a problem, depends on if they've set up copyright assignments or not | 15:59.08 |
henrys | indeed | 15:59.18 |
| sometime you have projects that are single handed enough to pull that off but probably not this. | 15:59.56 |
| kens:how was your 1 week bug? | 16:00.31 |
kens | DOne! | 16:00.39 |
| THanks to chrisl | 16:00.43 |
tor7 | abiword is all c++ so scratch that | 16:00.46 |
ray_laptop | abiword doesn't look very active. The last release was June 2010 | 16:00.53 |
henrys | chrisl:I assume you saw the urw status | 16:01.08 |
chrisl | henrys: I did - I'll keep quiet until someone pokes me about it | 16:01.29 |
ray_laptop | I can't believe that something as difficult as Office doc stuff wouldn't need more releases | 16:01.34 |
chrisl | ray_laptop: I suspect abiword's pre-xml importers are "good enough", and likely to stay that way | 16:02.39 |
kens | henrys I'm glad the bug is finished, |I was beginning to worry.... | 16:02.48 |
ray_laptop | I want to see what anybody thinks about making the saved-pages a little more idiot proof. | 16:03.04 |
| 1. accepting -saved-pages (adding a special check for this). It's not likely someone will want to set a string named "aved-pages" | 16:03.06 |
| 2. If --saved-pages=begin or --saved-pages-test is placed before -sDEVICE= don't take immediate action, but wait until we do the init2 | 16:03.07 |
| (Marcos tripped over this in setting up the weekly test of --saved-pages-test) | 16:03.09 |
| does anybody have objections to either of those ? | 16:03.23 |
henrys | kens:yeah I hope we don't have many like that in the future. | 16:03.25 |
Robin_Watts | ray_laptop: They both smell like special cases. | 16:03.29 |
marcosw | ray_laptop: speaking of --saved-pages-test, could you look at http://bugs.ghostscript.com/show_bug.cgi?id=694604 ? | 16:04.04 |
Robin_Watts | ray_laptop: In general I dislike second guessing the users intentions. | 16:04.31 |
ray_laptop | Robin_Watts: (2) is really not a special case, but just making --saved-pages-test and --saved-pages=begin more like most other command line options, in that they can go anywhere | 16:04.37 |
henrys | marcosw: was there any effort to find duplication in pcl and gs fuzzing - many tracebacks I see have to be common graphics library problems. | 16:05.20 |
Robin_Watts | In what way is that not a special case? | 16:05.20 |
ray_laptop | but I agree that (1) is a special case to accomodate people that can't read the docs correctly | 16:05.23 |
Robin_Watts | Currently, AIUI, our command line options are all processed in order. | 16:05.36 |
| so why should --saved-pages-test be any different to that? | 16:06.15 |
ray_laptop | Robin_Watts: right now, requiring that the --saved-pages-test or --saved-pages=begin follow the -sDEVICE=___ is a special case for these options | 16:06.28 |
marcosw | henrys: no, I didn't consolidate pcl and gs fuzzing issues. Just go ahead and fix all of the fuzzing bugs in either pcl or gs and I'll re-run the other one :-) | 16:06.43 |
henrys | marcosw: ;-) | 16:07.15 |
ray_laptop | right now, changing the order of most options on the command line still works the same way | 16:07.16 |
henrys | just looking over the bugs in the agenda | 16:08.07 |
ray_laptop | most device parameter options don't get processed in order -- they get collected and then sent to the device all at once. | 16:08.55 |
henrys | kens:you can bounty 693363 to shelly if you want. | 16:08.55 |
kens | henrys I haven't had a chance to look at that one, I keep forgetting about it | 16:09.32 |
| I tend to ignore XPS problems on the whole | 16:09.49 |
henrys | kens: hence my suggestion ;-) | 16:10.07 |
kens | henrys I think I wanted to look at it mself, IIRC its part of high level patterns, and the code construction made me think the scoping was deliberate. | 16:11.04 |
| And it was me that wrote it... | 16:11.14 |
henrys | takanesan has purchased the jeitta files and he is mailing the cd to my house. I didn't know if I should try getting him to rip the cd and transferring .. this seemed easiest. | 16:12.12 |
ray_laptop | henrys: do you have all of the apps to let you create PCL's or PDF's ? | 16:13.03 |
henrys | ray_laptop:not all no | 16:13.28 |
| I'll be happy to cover a couple apps to start | 16:14.21 |
| chrisl: how's your main project going? | 16:15.20 |
chrisl | henrys: it's not, really. I've been looking at the PCL performance bug | 16:15.45 |
marcosw | henrys: I just went through the pcl fuzzing seg faults and there were 3 or 4 that appear to be the same as one of the gs ones. I've closed those as duplicates. | 16:15.50 |
Robin_Watts | henrys, paulgardiner: http://cgit.freedesktop.org/libreoffice/core/tree/oox | 16:16.07 |
chrisl | henrys: but I've also had a really awful cold, which is slowing me down a bit :-( | 16:16.14 |
Robin_Watts | It seems the docx support in LibreOffice is indeed in C++ rather than java. | 16:16.25 |
henrys | chrisl: speaking of performance is there some nice way that we could gather stats on cache hits for a job - a debug option. I think that would be a good thing to have. | 16:17.20 |
marcosw | I may have missed some, but most of the pcl seg faults are in in source files in the pl or pxl directories, so can't be duplicates. | 16:17.22 |
henrys | marcosw: okay thanks I must have just chosen to look at a not so random sample. | 16:17.57 |
chrisl | henrys: I thought there was such an option.... | 16:18.01 |
henrys | chrisl: the code is all there to tell you but it isn't very friendly. | 16:18.29 |
Robin_Watts | --debug=char-cache-detail ? | 16:18.43 |
henrys | -ZK tells you quite a bit - I imagine you could write a script to parse the output and get the cache hit rate but... | 16:19.19 |
Robin_Watts | henrys: So you want --debug=char-cache-summary or something ? | 16:19.51 |
chrisl | I can look into it - either a script to parse out the info, or something internal. | 16:20.19 |
mvrhel_laptop | chrisl; I feel for you. I came down with a bad cold yesterday | 16:20.20 |
henrys | chrisl, mvrhel_laptop I hope you guys get better soon. | 16:20.42 |
mvrhel_laptop | henrys: just so you know, I have been working hard to get this knockout stuff working | 16:20.59 |
chrisl | mvrhel_laptop: this cold just keeps coming back - this is the third iteration, and it just won't go away :-( | 16:21.09 |
henrys | chrisl: obviously not terribly important. | 16:21.10 |
mvrhel_laptop | in the process I have found a number of problems in the transparency code that will be fixed with this when I get it wrapped up, hopfully this week | 16:21.41 |
chrisl | henrys: well, it ties into my other *very* background "project" - I feel our glyph cache isn't optimal | 16:21.42 |
mvrhel_laptop | then I want to jump back to mupdf | 16:21.51 |
henrys | mvrhel_laptop: okay yes I noticed you got sucked back into gs | 16:22.13 |
| chrisl: seems to me -ZK could output at the end of job the hit rate. | 16:22.52 |
| Robin_Watts: one more thing - we are adamant not to use a global for the openjpeg allocator - if we can do that things are easy. | 16:23.55 |
chrisl | henrys: it could - I'm generally not keen on having to keep such data internally, though. It can complicate stuff | 16:24.04 |
Robin_Watts | henrys: right. | 16:24.53 |
henrys | chrisl: fair enough - "stats" are used with good frequency though in gs | 16:25.31 |
Robin_Watts | I've created a bug for the openjpeg allocator stuff and farmed it out to shelly. He was talking to the openjpeg people about it. | 16:25.47 |
| haven't heard any progress reports. | 16:25.53 |
henrys | Robin_Watts: okay | 16:25.56 |
| anything else for the meeting? | 16:26.25 |
chrisl | henrys: sure, I'd need to look into it to know either way - it may not introduce undue complications | 16:26.30 |
henrys | so we should adjourn, as usually I'll be around for a while. | 16:27.42 |
| s/usually/usual | 16:27.52 |
kens | OK goodnight all | 16:28.11 |
ray_laptop | Since only Robin_Watts objected to my --saved-pages changes, I guess I can proceed, or do I have to bring Robin_Watts around as well ? | 16:28.19 |
henrys | I didn't like the special case but I won't fight fiercely about it. | 16:29.01 |
ray_laptop | but I am thinking of just doing (2), not (1) respecting Robin_Watts' comment about "special case" | 16:29.07 |
kens | I don't object, but I@m not sure its terribly important, RTFM | 16:29.14 |
ray_laptop | well, if marcosw tripped over (2) then probably others will as well. | 16:29.58 |
marcosw | ray_laptop: as I mentioned in bug 694604 there are other order dependent command line issues with --saved-pages-test (i.e. putting it before or after the -r300 command changes the output, both are wrong, but differently). | 16:30.01 |
Robin_Watts | ray_laptop: I have to confess to not entirely understanding (2). Are you saying that --saved-pages-test etc fiddles with the current device? And that someone doing -sDEVICE=... then undoes that as it selects a different device or something ? | 16:30.36 |
ray_laptop | marcosw: right, and my changes will help that | 16:30.37 |
marcosw | great, wasn't sure if (2) only addressed the -sDEVICE= and --save-pages-test order dependency. | 16:31.19 |
ray_laptop | Robin_Watts: --saved-pages-test (and --saved-pages) need to execute "init2" to install the device, and doing that BEFORE the -sDEVICE or other device parameters causes problems | 16:31.52 |
Robin_Watts | Does -sDEVICE actually take immediate effect? | 16:32.09 |
| I thought that -sDEVICE just set a value in a dictionary. | 16:32.18 |
| and that the device was only setup when the next file (or ps command) was about to be run ? | 16:32.43 |
ray_laptop | Robin_Watts: no. All of the options are deferred until init2 (which is done prior to running a file, or a -c option) | 16:32.46 |
Robin_Watts | Right, so why can't --saved-pages-test just set a flag or something, and that can be done after the init2? | 16:33.09 |
| Maybe that's what you're suggesting. | 16:33.18 |
ray_laptop | Robin_Watts: so for (2) I was going to make --saved-pages-test act that way as well ... wait until we do init2 | 16:33.39 |
| Robin_Watts: exactly. | 16:33.55 |
Robin_Watts | OK, so that sounds perfectly sane to me :) | 16:33.58 |
ray_laptop | cheers | 16:34.09 |
marcosw | wait, now that Robin_Watts thinks it's a good idea I'm going to change my mind and say that I prefer keeping it the way it currently is :-) | 16:34.51 |
ray_laptop | thanks, Robin_Watts (et al.) for the feedback | 16:34.51 |
ray_laptop | ignores marcosw (as usual) ;-) | 16:35.14 |
marcosw | I've already spent all this time refactoring the regression code to deal with the command line order dependency and that work is all going to have been a waste of energy... | 16:36.00 |
ray_laptop | marcosw: I'll have my son play you a sad song on the violin ;-) | 16:37.19 |
mvrhel_laptop | overprint simulation with transparency is a pain | 16:40.16 |
| taking a break for a bit. need to go to airport to pick up my father | 16:43.37 |
ray_laptop | I've finished going through the bmpcmp for saved-pages-test mode with my fixes. there were lots of minor diffs, but a few actual bugs surfaced. I have to see if those are just due to clist mode, since most of the diffs were .0 (page mode) and saved-pages forces clist mode. | 16:44.15 |
Robin_Watts | anyone remember the name of a file with stroked text in it offhand? | 17:12.52 |
| got one. | 17:48.41 |
mvrhel_laptop | still have a file with issue :( | 23:55.28 |
| issues | 23:55.32 |
| and of course it is some massive file... | 23:56.31 |
| Forward 1 day (to 2013/10/09)>>> | |