| | <<<Back 1 day (to 2013/09/30) | 2013/10/01 |
| marcosw | rayjj: I can log into peeved just fine. Should I set it up as a cluster node? | 04:49.41 |
| | Robin_Watts_ and rayjj: I've added peeved to bind; it will take another hour or so for the update to propagate. | 04:54.34 |
| mvrhel_laptop | done for the night | 05:31.02 |
| kens | tor7, we're out of luck on premium economy | 06:57.50 |
| | Delta say they can't book it on their systems, because they don't do PE, we need to tlak to Virgin. Virgin say they can't book it, we need to talk to Delta.... | 06:58.22 |
| | My current planis to try and upgrade at the airport...... | 06:58.40 |
| tor7 | damn. well, at least that should mean that nobody else can either. | 07:00.01 |
| kens | I think if they have booked with Virgin direct they can | 07:00.17 |
| tor7 | oh. yeah. :( | 07:00.32 |
| | still early mornin' | 07:00.43 |
| kens | I have no idea why this is so difficult. I can understand Delta's position, their system doesn't *do* PE, Virgin baffles me totally | 07:00.43 |
| tor7 | incompetent clerks? | 07:01.45 |
| kens | Of course, teh Virgin manager told Stella we could have booked the whole trip with them, I pointed out we couldn't because they don't fly to Maui after October 31st. Last I heard he was still trying to make the booking to prove me wrong | 07:01.47 |
| | SO yes, incompetent staff (and this bunch are in the UK, they are only a few miles from here....) | 07:02.19 |
| tor7 | kens: I also need to get flights to gatwick, still haven't decided on which day to fly back. given how early we arrive at LHR, I'm considering taking an afternoon/evening flight back out of gatwick. | 07:09.03 |
| kens | tor7 that would work, we can get you to the airport in time for a afternoon flight | 07:09.24 |
| | As long as you think you can stay awake long enough to get home :-) | 07:09.41 |
| tor7 | that might be problematic :( | 07:09.55 |
| | but it's easier to take brief naps on flights east than west, at least | 07:10.10 |
| kens | OMG we arrive at 0635 | 07:10.17 |
| | Well, we should probably be back here by 9am so we could get you to Gatwick in time for a flight anytime after say 11 am | 07:11.06 |
| | Afternoon would probably be safer though | 07:11.22 |
| tor7 | afternoon would be less stressful, and allow for freshening up and lunch | 07:11.44 |
| kens | :-) | 07:11.57 |
| tor7 | kens: what time would be good to arrive on the 5th? | 07:15.45 |
| kens | Any time is fine | 07:15.55 |
| | Ah, before 5pm, we have to tkae Melanie riding I think that night | 07:16.17 |
| kens | checks calendar | 07:16.29 |
| tor7 | hm, they only have 3 flights on the 10th, 7:00, 12:50 and 19:50... | 07:16.45 |
| kens | Oh well any of those work, we'll be home again by ~8pm | 07:17.05 |
| | D'Oh! | 07:17.16 |
| | Wrong way :-) | 07:17.25 |
| | 12:50 is probably possible, but a bit risky | 07:17.48 |
| tor7 | I can take the flight arriving at 11:25 in that case, it's the most expensive (no wonder, best scheduled time, but the price diff is less than the train fare back and forth to the airport...) | 07:18.01 |
| kens | :-) | 07:18.11 |
| | 11:25 is just fine | 07:18.18 |
| | Flying out at 12:50 on the 10th should be OK I think | 07:19.06 |
| | Allows 2 hours for any problems and the M25 isn't usually that bad | 07:19.26 |
| tor7 | yeah, but missing that connection could be expensive if missed (since they probably won't hear of any excuses...) | 07:19.55 |
| | still, the 19:50 flight gets me home at around midnight | 07:20.18 |
| kens | Serously it should be fine, we'll be in a taxi coming home, if we get tight we'll go striaght to Gatwick | 07:20.27 |
| tor7 | so not very tempting... | 07:20.35 |
| kens | Its only ~1 hour from Heathrow to home if the roads are OK, and about 30 minutes to get out of the airport | 07:21.14 |
| | So we could be here by 8 am on a very good day, and shoud certainly be here by 9. Its 30 minutes from here to Gatwick airport. | 07:21.51 |
| | And we need to get you there by 11:30'ish, so leave here at 11 am. | 07:22.08 |
| | SO 2 hours leeway | 07:22.13 |
| tor7 | right. easyjet sells one-way flights the same day for no more than the regular highest price they list | 07:22.25 |
| | so that ought not be a significant issue | 07:22.34 |
| kens | Seems reasonable then | 07:22.53 |
| tor7 | their "business" pricing is still cheaper than economy flying BA or SAS :) | 07:23.16 |
| kens | :-) I have no idea what business class on EasyJet woudl be, maybe a free cup of coffee ? | 07:23.47 |
| tor7 | guaranteed space in the cabin for your hand baggage :) | 07:24.03 |
| | it's one of the items on their "FLEXI" rate upgrade list | 07:24.26 |
| kens | Ah! | 07:24.26 |
| | Yes, we used that flyong to Berlin | 07:24.39 |
| tor7 | but it also gets you the airport benefits of fast track and all that stuff | 07:24.42 |
| kens | Yes, its actually worth it for us | 07:24.53 |
| | and not very expensive either | 07:25.08 |
| tor7 | and you get to put a bag in the hold... | 07:25.09 |
| | no, it's still quite reasonable pricing | 07:25.15 |
| kens | Oh didn't knwo that, we flew cabin bags only | 07:25.28 |
| tor7 | I'll just remember to buy a new cabin bag, mine is good but annoyingly large at times | 07:25.36 |
| | the wheels sometimes make it not fit on the small city hopper planes :( | 07:25.51 |
| kens | I think I need a smaller laptop, the bag is fine.... | 07:26.00 |
| tor7 | kens: You can take my laptop if you can stomach using a Mac ;) | 07:26.28 |
| kens | Macs hate me | 07:26.37 |
| | I used to be abl;e to break them by walking past | 07:26.45 |
| | Admitteldy that was in the days of system 7 | 07:27.01 |
| tor7 | I've been looking (drooling) at the Asus Zenbook line of 13" laptops with 1920x1080 IPS panels | 07:27.01 |
| kens | AH yes, there was a new Asus being reviewed hte other day | 07:27.21 |
| tor7 | kens: well, system 7 was quite capable of breaking all on its own with no help from the user :) | 07:27.22 |
| kens | :-) | 07:27.27 |
| tor7 | shoe-horning multi-tasking into that OS, what were they thinking? | 07:27.46 |
| kens | Also I saw a runour on the reg about a 280 dpi screen, the rumour was Apple were going to use it | 07:27.52 |
| | http://www.theregister.co.uk/2013/09/30/sharp_hopes_to_wow_apple_with_igzo_4k_laptop_display/ | 07:28.31 |
| tor7 | bah. dollar's plummeted again. it's not good, this bankrupt economy mess... | 07:33.03 |
| kens | Its the guvmint this time. | 07:33.18 |
| | Failing to agree a budget | 07:33.28 |
| tor7 | My monies! They're trapped in a dollar account :( | 07:33.49 |
| kens | Or at least, that's what caused Wall Street to drop | 07:33.55 |
| | You should complain to your US senator, or congreeman :@) | 07:34.29 |
| tor7 | if they can't pay their loans, will the banks of china take their homes? would be fun, if the white house turned into bank of china :) | 07:34.30 |
| kens | Apparently air traffic control isn't one of the affected armsof government | 07:38.23 |
| tor7 | kens: okay, flights to gatwick booked. coming in the 5th at 11:25 and departing the 10th at 12:50 | 07:38.59 |
| kens | Cool, we'll see you then | 07:39.11 |
| | Sent myself an email so I won't forget | 07:40.39 |
| tor7 | kens: I can forward the itinerary email if you like | 07:41.22 |
| kens | Not a bad idea, then I'll have your flight number too | 07:41.37 |
| tor7 | kens: sent. | 07:42.09 |
| kens | THanks | 07:42.13 |
| | Got it, thanks Tor | 07:43.20 |
| | Ah I was just wondering where chrisl was | 07:44.16 |
| chrisl | What now, or over the last few days? | 07:45.34 |
| kens | Just now | 07:45.41 |
| | I knew you had holiday until today | 07:45.53 |
| | I've got a weird problem I'd like to talk ove rwith you when you have a little time | 07:46.09 |
| chrisl | Okay, let me finish my e-mail, then I'll be good | 07:46.43 |
| kens | No problem, I'll fetch a coffee, brb. Also will send an email with an attachment | 07:46.58 |
| tor7 | kens: http://press.asus.com/asus-announces-zenbook-ux301-and-ux302-with-sleek-glass-finish/ these ones? | 07:58.21 |
| kens | THat looks like it | 08:04.54 |
| | The reviewer wasn't impressed with the Bang & Olufsen audio though,thought the sub-woofer was an irritiant and the regular speakers tinny | 08:05.36 |
| | Good grief, someone actually using txtwrite | 08:06.57 |
| tor7 | my only real gripe with that would be the 16:9 aspect ratio... | 08:07.19 |
| | the chromebook pixel is oh so tempting | 08:07.29 |
| kens | :-) | 08:07.34 |
| | I can happily live without the touch screen.... | 08:08.16 |
| chrisl | kens: okay, I'm looking at the code now....... | 08:21.51 |
| kens | chrils OK | 08:21.57 |
| | The problem is that if I apply that block of code, japan-.ps works and the other one (activePDF file) doesn't. If I remove it the reverse is true. | 08:22.41 |
| | Running the test suite wiht it removes shows a number of diffs, about half of which are greressions and half are progressions. | 08:23.05 |
| | So clearly there's something really screwed up going on | 08:23.14 |
| chrisl | So, this code is called in the context of a show operation? | 08:23.22 |
| kens | Yes, in this case (I think) a regular show. It was an xshow but I changed it | 08:23.43 |
| | We are modifying the current poitn before beginning to 'draw' the text, and I can't really figure out why. | 08:24.08 |
| | It is, of course a complex case. Its a CIDFont where the font and descendant have different matrices, and its in teh context of a Windows job, so the y axis is flipped | 08:24.51 |
| | and the active PDF file is rotated as well. | 08:25.01 |
| chrisl | In that case, my first confusion is: during a show, IIRC, the gstate CTM already "includes" the font matrix. So why do the transform with the font matrix, and then the ctm? | 08:25.10 |
| kens | I wouldn't count on the CTM including the font matrix, this is pdfwrite | 08:25.35 |
| | But it looks like we are using those matrices to get the width of the glyph into the current space | 08:26.05 |
| | and tehn 'add' it to the current point | 08:26.17 |
| | I'm just trying to figure out where the rotation takes place in the activePDF file, to see if I can take it out tooo | 08:27.02 |
| mupdf_noob | Good morning. Are there any MuPDF developers here? | 08:27.54 |
| | I'm having difficulties in compiling the source on CentOS linux. It's a headless virtual machine and make fails dramatically with following error messages about X11: platform/x11/x11_main.c:3:22: error: X11/Xlib.h: No such file or directory | 08:29.20 |
| kens | chrisl OK so I removed the rotation | 08:30.26 |
| mupdf_noob | Does, MuPDF require desktop environment or is it possible to compile it for a headless VM? All I need is the mudraw program. | 08:30.44 |
| chrisl | kens: so, in both cases the the Type 0 font has rotation in the matrix, and so does the subfont. But in japan-.ps the ctm rotated, and in the other file it isn't | 08:31.37 |
| kens | Correct. Except that I've now removed the rotation from the other file too | 08:32.02 |
| | the CTM in the text state does not include the font matrices at this point | 08:32.39 |
| | which is why (I guess) we apply them to the width | 08:32.48 |
| | CTM now is [0.12 0 0 0.12 0 0] | 08:33.05 |
| chrisl | I'm wondering if, in a composite font, we should only transform by the subfont matrix, and not the Type 0 matrix..... | 08:33.13 |
| kens | I think we've been round this loop with the rendering code, which is why I wanted to dicsuss it with you, I cannot remember the answer | 08:33.43 |
| | FWIW with the CTM 'normalised' I get the same wrong answer | 08:34.09 |
| | and if I remove that block of code , the correct result | 08:34.21 |
| | I think it is required to apply the parent FotnMatrix, as that seems to contain the font scaling | 08:35.12 |
| | I do a breakpoint on the if (v.x != 0... line | 08:35.47 |
| | with the 'green' file I see subfont matrix is [0 1 -1 0 0 0] | 08:36.19 |
| | parent FontMatrix is [0 75 75 0 0 0] | 08:36.49 |
| | CTM is [0.12 0 0 0.12 0 0] | 08:36.58 |
| | let me try the japan file. | 08:37.04 |
| tor7 | mupdf_noob should have waited one more minute before losing patience... | 08:37.40 |
| kens | tor7 agreed | 08:37.46 |
| | chrisl subfont FontMatrix is the same | 08:37.54 |
| | parent FontMatrix is [0 88 88 0 0 0] | 08:38.15 |
| | CTM is [0.12 0 0 -0.12 0 0] | 08:38.47 |
| | So essentially the same (ignoring the y flip, I'll just og put that back) | 08:39.02 |
| | Oops putting the y fli pback in makes the content com out off the page.... | 08:40.08 |
| | OK fixed that. So the CTM is the same, the font matrix is the same (barring scaling), the subfont matrix is the same and the result is incorrect. | 08:42.25 |
| | So I'mkind of puzzled as to what the difference is and why one works and one doesn't (both render correctly of course) | 08:43.04 |
| chrisl | It's possible that japan-.ps is actually "wrong", but just happens to look "correct" | 08:44.14 |
| kens | No I compared it against the Distiller output, and its correct | 08:44.29 |
| | WIth that block of code | 08:44.36 |
| chrisl | What I mean is that it might be getting the right numbers for that case, but for the wrong reasonws | 08:45.06 |
| kens | THere are other test files which are more obviously correct with the code and incorrect wihtout it, but they were more complicated examples | 08:45.10 |
| | chrisl that's possible, one of the CET files is wrong with the code *and* without it, but in interestingly different ways | 08:45.41 |
| | If you look at my last bmpcmp you can see 093-01.ps is one example | 08:47.03 |
| | THat's a run with the code block removed by the way | 08:48.22 |
| | Oh interesting. | 08:50.46 |
| | 093-01.ps is 'wrong' when rendered adn compared against distiller | 08:51.04 |
| kens | hates CIDFonts and Metrics | 08:54.39 |
| chrisl | Yeh, 093-01.ps has always been wrong - IIRC, I think Jaws got it wrong, too..... | 08:55.13 |
| kens | Ah, fair enough | 08:55.22 |
| | THere musty be something crazy gong on there | 08:55.30 |
| chrisl | I think so - I might even get to investigate it, at some point! | 08:56.00 |
| kens | I guess I'm uzzled as to why pdfwrite is applying this offset to the curretn point, which appears to be calculated off the width returned by the CDevProc | 08:56.40 |
| | I don't really see why it should be required. | 08:56.55 |
| chrisl | Presumably it's because of the way pdfwrite "manually" positions glyphs, instead of leaving it to the font metrics? Although, I'd have expected it only when wmode == 1 | 08:59.19 |
| kens | pdfwrite usually does leave it up to the font metrics, it only positions glyphs individually when it has to | 09:00.01 |
| | and in btoh these cases hte wmode is 1 | 09:00.28 |
| chrisl | Yes, I'd expect it both test cases, but I would expect the conditional to also check for wmode, as well as the offset being non-zero | 09:01.17 |
| kens | Hmm, well possibly. the wmode 0 cases all seem to be OK as far as I know | 09:01.39 |
| | The only thing I notice is that in the case of the incorrect file, real_width.v.y is > Wodth.v.y whereas in the other case its less | 09:02.29 |
| | Oh, I wonder if v.x and v.y are always 0 when we have a wmode 0 font | 09:04.25 |
| chrisl | In which case, it would be much simpler just to check the wmode, wouldn't it? | 09:05.06 |
| kens | You would think so yes | 09:05.18 |
| | I'm pretty sure I didn't write this code though | 09:05.39 |
| chrisl | So, the subfont rotation is coming from the CMap...... | 09:07.00 |
| kens | Ah, well it is a vertical cmap | 09:07.13 |
| | I'm assuming this is using a horizontal font to do vertical writig | 09:07.25 |
| chrisl | Yes, and forcing the vertical writing using the CMap | 09:07.45 |
| kens | Hacky | 09:07.52 |
| | Butits a TT font so not too surprising | 09:08.02 |
| | It looks like v.x and v.y are the distance from origin 0 to origin 1 (definiition in setcachedevice2), presumably we have to add this manually since PDF doesn't *have* a\ setcachedevice2 or a CDevProc equivalent | 09:09.20 |
| | So perhaps this is what the code here is all about. | 09:09.31 |
| chrisl | But the origin movement should be handled by the interpreter when it encounters a wmode == 1 font | 09:10.30 |
| kens | In PostScript yes, but not in PDF because there is no way to do so | 09:10.51 |
| | I think | 09:10.56 |
| | Its all a bit hazy still. But I think there is no CDevProc in PDF | 09:11.10 |
| | I think there is an equivalent to setcachedevice 2,is it d1 ? | 09:11.42 |
| chrisl | Hmm, but only type 3 fonts call d0/d1 explicitly | 09:12.07 |
| kens | So that's probably what this all comes down to then. PostScript fonts can (and in this case do) have a CDevProc which potentially changes the metrics | 09:12.46 |
| | also d1 is equivalent to setcachedevice | 09:13.09 |
| | Seems there is no equivalent to setcachedevice2 | 09:13.27 |
| chrisl | Can you (easily) force pdfwrite to position every glyph explicitly? | 09:13.49 |
| kens | No | 09:13.57 |
| | If I'mright, we cna only get v.x and v.y set if we get a call to setcachedevice2 | 09:15.16 |
| | and indeed pdfwrite has a method for setcachedevice2 and does special stuff if we're in a CDevProc | 09:16.36 |
| chrisl | I think the rendering one does special stuff there, too | 09:19.12 |
| kens | We are definitely copying the 10 numbers and squirelling them away, we then seem to use them to set up the Widths values | 09:19.47 |
| chrisl | The 10 parameters to setcachedevice2 or the results of teh CDevProc? | 09:20.26 |
| kens | The 10 params to setcachedevice2 | 09:20.44 |
| chrisl | I'd have thought you'd want the values returned from the CDevProc...... | 09:21.29 |
| kens | But CDevProc has to call setcachedevice2 to set its values doesn't it ? | 09:22.06 |
| | let me check | 09:22.10 |
| | RIght, the 10 operands resulting from CDevProc are passed directly to setcachedevice2 | 09:23.11 |
| | page 365 of the plrm | 09:23.32 |
| | So by catching setcachedevice2 we are getting the numbers which were returned byCDevProc, not the numbers passed into it | 09:24.08 |
| | pdf_glyph_widths() returns those values | 09:25.10 |
| chrisl | Okay, so confusion over our internal stuff, and the "real" world - never mind...... | 09:25.35 |
| kens | I guess so | 09:25.47 |
| | I think the code in that block is intended to duplicate the setcachedvice2 stuff where the origin is translated when in writing mode 1 | 09:26.19 |
| | Still baffled as to why it doesn't work in this case though | 09:29.26 |
| chrisl | Hmm, doesn't seem to like my naive removal of the CDevProc :-( | 09:35.28 |
| kens | There's an awful lot of CDevProc definitions, japan-.ps has a way of modifying the CDevProc if you look near the end of it | 09:36.14 |
| | Hmm but that didn't work when I tried to use it in the other file | 09:37.59 |
| chrisl | Removing the CDevProc from 8f6459-12.ps seems to result in consistent output between pdfwrite and rendering...... | 09:39.07 |
| kens | I guess that's not surprising. It will cause v.x and v.y to be 0, and will therefore not perform that block of code | 09:39.36 |
| chrisl | Nope, v.x and v.y are non-zero without the CDevProc | 09:41.06 |
| kens | Interesting | 09:41.17 |
| | Possibly they work out to 0 whenapplied then ? | 09:41.36 |
| | Because we are using the Metrics from teh font | 09:41.49 |
| chrisl | ppts->values.matrix.tx = 1243.74158 | 09:42.21 |
| | ppts->values.matrix.ty = 3371.3999 | 09:42.37 |
| kens | that looks correct yes | 09:42.46 |
| chrisl | Does the CDevProc in japan-.ps actually generate new metrics values, or do the returned values from the CDevProc work out the same (or close) the the "real" metrics? | 09:44.25 |
| kens | Good question | 09:44.37 |
| | To which I don't know the answer | 09:44.50 |
| | They are close but not the same | 09:45.27 |
| | As far as I can see | 09:45.33 |
| | I need to go look at the Metrics2 entries | 09:47.53 |
| | No they are different | 09:48.51 |
| | The last entry of the 10 differes significantly, 0.07 on input, 0.859 on output from CDevProc | 09:49.28 |
| | The CDevProc results from 8f6459...ps are basically the same, except that the 10th number is even larger | 09:53.12 |
| | 0.046 becomes 2.21 | 09:53.27 |
| | Hmm, here's something odd | 09:54.42 |
| | japan-.ps dumps the Metrics2 for both the fonts in the FDepVector. I modified 8f6459 to do the same. | 09:55.16 |
| | japan-.ps gets the Metrics2 entry form FepVector[0], 8f6459 gets the Metrics2 entry from FDepVector[1] | 09:56.15 |
| | That is, those are the numbers passed into the CDevProc for the 10th value | 09:56.47 |
| chrisl | So, 8f6459 has more than one descendant? | 09:57.27 |
| kens | They both do | 09:57.33 |
| | Of course that Metrics2 value doesn't seem to get used anywhere | 09:58.42 |
| | Its just an interesting observation | 09:59.04 |
| chrisl | kens: they both appear to one descendant font | 10:02.46 |
| kens | THis gets different answers: | 10:03.18 |
| | currentfont /FDepVector get 0 get dup /CDevProc get == | 10:03.18 |
| | currentfont /FDepVector get 1 get dup /CDevProc get == | 10:03.18 |
| | oops no, that didn't paste correctly | 10:03.29 |
| | currentfont /FDepVector get 0 get dup /CDevProc get == | 10:03.42 |
| | currentfont /FDepVector get 1 get dup /CDevProc get == | 10:03.42 |
| | Grrr | 10:03.46 |
| | "currentfont /FDepVector get 0 get dup /CDevProc get == | 10:03.53 |
| | "/Metrics2 get {== ==} forall | 10:03.54 |
| | "currentfont /FDepVector get 1 get dup /CDevProc get == | 10:03.54 |
| | "/Metrics2 get {== ==} forall | 10:03.54 |
| | Ignore the " | 10:03.59 |
| | currentfont of course is the CIDFont at the time | 10:04.15 |
| Robin_Watts | tor7: ping | 10:04.45 |
| tor7 | Robin_Watts: hi | 10:04.53 |
| Robin_Watts | tor7: hi. | 10:04.57 |
| | So, various things... | 10:05.02 |
| | 1) There are some reviews on robin/master for you. | 10:05.11 |
| tor7 | your second commit looks fine, still haven't brought myself to understand the details of the first one | 10:05.20 |
| Robin_Watts | 2) Have you had a chance to look over the JNI bindings? | 10:05.31 |
| kens | chrisl if I do "currentfont {== ==} forall" then I get /FDepVector [-dict- -dict-] | 10:05.33 |
| chrisl | kens: okay, I see - more confusion about how the "fstack" crap works | 10:05.39 |
| tor7 | Robin_Watts: the const part of the jni branch LGTM | 10:05.49 |
| kens | oh its crap alright | 10:05.50 |
| tor7 | still haven't looked at the JNI stuff, was hoping to take a look at that and mirroring them in Lua soon to see how things fall out | 10:06.26 |
| Robin_Watts | tor7: Have you looked at the "Disable image interpolation" one ? | 10:06.29 |
| tor7 | but the stencil clipping is madness trying to debug | 10:06.37 |
| Robin_Watts | yeah, I can imagine. | 10:06.48 |
| | and I was just looking at bug 692930 | 10:07.04 |
| | I *think* it's to do with xps not transforming the areas for tiles etc correctly. | 10:07.30 |
| tor7 | Robin_Watts: disable image interpolation LGTM | 10:07.33 |
| kens | chrisl I 'guess' that its simply the larger CID mapping the glyph to the second descendant | 10:07.33 |
| Robin_Watts | but it's hard to be sure. | 10:07.36 |
| | I am having no luck cutting the file down any further, possibly because I don't speak xps. | 10:08.02 |
| tor7 | Robin_Watts: hm, I'd forgotten all about bug 692930 | 10:08.24 |
| | yeah, it was something odd with the transforms IIRC. | 10:08.50 |
| Robin_Watts | tor7: The clipping strokes stuff; I've tried many many versions of the code under the cluster, and fallen down many holes. | 10:09.07 |
| chrisl | kens: I made the mistake before: I thought we "flattened" the entire font "tree" into the fstack, but we don't, we only keep the "linear" path from composite font to base font | 10:09.13 |
| Robin_Watts | the version that's there now passes all the cluster tests (with just about 11 diffs due to antialiasing differences due to rounding). | 10:09.31 |
| tor7 | I seem to recall that one being down to the order of the tiles as well, really hard to pin down | 10:09.57 |
| Robin_Watts | yeah. I hate tiling :( | 10:10.14 |
| tor7 | Robin_Watts: well, if you're confident go ahead without my blessing | 10:10.16 |
| Robin_Watts | I am confident in the stroke clipping stuff (as much as you can ever be with such things). If you're happy with the overall structure, I'll go for it. | 10:10.48 |
| tor7 | I just want to understand the code, I'm sure it ought to work well enough. and rounding differences are to be expected when you start adding clipping. | 10:10.50 |
| kens | chrisl I just tried changing the CID and got the correct glyph, but rotated, I wonder what I did wrong.... | 10:11.18 |
| tor7 | it's just so much code... I can't help but think it could be done simpler | 10:11.25 |
| Robin_Watts | tor7: essentially I find a bounding clipping rectangle at the start of the stroking process (from the gel). | 10:11.27 |
| | Then for each line, if the start endpoint is off this rectangle, I move it up to the edge of the rectangle (allowing for the dash pattern/phase/on-off ness). | 10:12.27 |
| chrisl | kens: could be you landed on an value not mapped by the cmap, and ended up with that crazy partial match nonsense? | 10:12.36 |
| tor7 | Robin_Watts: yeah. getting the scissor from the gel feels ugly, but it's probably simpler than passing the scissor down through the entire path stroking pipeline. | 10:12.50 |
| kens | It sort of looks like I ended up with a horizontal unrotated glyph. | 10:12.56 |
| | which is placed at the 'correct' point.... | 10:13.14 |
| Robin_Watts | tor7: it is more code than I'd hoped, but I couldn't trivially see how to reduce it's volume. | 10:14.12 |
| tor7 | Robin_Watts: the basic idea of the moved_horizontally clauses is easy to grasp, and needs to be that big unless adding a lot of generic "clip" functions with a dozen arguments | 10:14.29 |
| Robin_Watts | At least is should pretty much all be skipped in non-clipping cases. | 10:14.40 |
| | tor7: yeah we'd need to pass in and get back lots of variables. Nasty. | 10:15.01 |
| tor7 | adjust_for_tail is to forward the dash state when skipping an entire segment? | 10:15.12 |
| Robin_Watts | Suppose the line to be plotted is a to b. | 10:15.50 |
| | then consider 2 new points A and B which are where that line intersects with the clipping rect. | 10:16.08 |
| tor7 | Robin_Watts: hold that thought, I'm being called for lunch (I'll check the logs when I get back) | 10:16.12 |
| Robin_Watts | so we actually want to skip a to A, then draw A to B then skip B to b. | 10:16.21 |
| | adjust_for_tail does the skipping of B to b. | 10:16.34 |
| tor7 | ah, right. | 10:16.41 |
| Robin_Watts | move_horizontally and move_vertically together do skipping a to A. | 10:16.46 |
| | and if the WHOLE line is off the rectangle, then adjust_for_tail doubles up duty and does both. | 10:17.01 |
| tor7 | and if a to b lies outside entirely, that case is handled by adjust_for_tail as well | 10:17.10 |
| | right. got it. | 10:17.16 |
| Robin_Watts | You go for lunch. I'll go for a run :) | 10:17.22 |
| kens | Oh interesting, the CDevProc for the font looks to be crap, it removes teh CID< then uses the ury as the vy offset | 10:22.18 |
| | THat's where the numbers are coming from. I need to think about this a bit. | 10:22.44 |
| | THanks for looking at it chrisl | 10:22.52 |
| chrisl | kens: okay, that's good - 'cause I'm just getting confused. I'll look again later, if you haven't got further | 10:24.36 |
| kens | Thanks, I think I need to go andwork out what the PostScript is doing with the value. I'm not convinced its sensible | 10:25.55 |
| kens | is still confused, and goes to lunch | 11:15.25 |
| Robin_Watts | So, are we using jasper or openjpeg in gs now ? | 11:44.01 |
| kens | I thought OpenJPEG | 11:51.03 |
| Robin_Watts | yeah, it's just not in the ghostscript.vcproj. Just added it. | 11:51.47 |
| | openjpeg still calls malloc/free. | 11:52.01 |
| | We can get around that by defining ALLOC_PERF_OPT when building it, and it'll call opj_malloc/calloc/free, and we can replace them. | 11:52.30 |
| | BUT... we'd need to replace them with versions of malloc that align to 16 bytes unless we perform some surgery. | 12:04.48 |
| | But then again, maybe we should move gs to openjpeg 2. | 12:06.55 |
| | Ah, but it's identical code in that :( | 12:07.46 |
| | which means mupdf is similarly reliant on malloc/free :( | 12:08.15 |
| | God, how can libraries get this basic stuff so wrong in this day and age? | 12:12.16 |
| tor7 | in this day and age, I think we should just be happy that we don't have to use javascript frameworks or piles of ruby spaghetti ;) | 12:24.33 |
| Robin_Watts | tor7: So, did you end up happy with the clippy stroky stuff? | 12:26.08 |
| tor7 | Robin_Watts: yes. push push. | 12:26.18 |
| Robin_Watts | tor7: urgh, possibly, yes. | 12:26.21 |
| | oh, gawd. There is no concept of 'context' in opj. | 12:33.52 |
| | So we can't get a gs_memory_t or an fz_context * to the malloc functions. | 12:34.16 |
| | Is it time to start using Luratech in mupdf, I wonder... | 12:35.11 |
| | Must remember to bring that up at the meeting later. | 12:40.13 |
| sebras2 | Robin_Watts: hey! you fixed the fuzzes. | 12:51.33 |
| Robin_Watts | sebras2: I did. | 12:51.41 |
| | Please don't do that again :) | 12:51.50 |
| sebras2 | Robin_Watts: :) | 12:52.15 |
| Robin_Watts | (actually, that's rubbish, it was much appreciated) | 12:52.18 |
| sebras2 | Robin_Watts: I know. It would probably be hard to find this problem without fuzzing. | 12:52.50 |
| | Robin_Watts: though one should try to fuzz sufficiently simple files. | 12:53.03 |
| | Robin_Watts: and only go for the big ones when we fail to find problems in the simple ones. | 12:53.23 |
| Robin_Watts | sebras2: yeah. | 12:53.38 |
| | The problem with fuzzing large PDF files is that my standard techniques for making them small ones don't always work :( | 12:54.13 |
| | I don't mind cutting PDF files on the whole (pdfclean makes it much easier). | 12:54.32 |
| sebras2 | Robin_Watts: no pdfclean is all of a sudden not your friend... | 12:54.32 |
| Robin_Watts | but if pdfclean stops working... | 12:54.42 |
| sebras2 | mmm. btw, did I get it right if I belive that marcosw fuzzed your nightly test files as well? | 12:55.07 |
| | in that case I think it really _was_ worthwhile to describe how to use zzuf. :) | 12:55.23 |
| Robin_Watts | sebras2: I think he has been experimenting with fuzzing, yes. | 12:55.32 |
| kens | He's distributing headaches with an even hand now I believe | 12:55.51 |
| | Starting with henry :-) | 12:56.04 |
| Robin_Watts | but we all have lots of outstanding "automatically generated bugs", so there is limited point in generating more and more and more of them. | 12:56.05 |
| | lunchtime for me, bbs. | 12:56.11 |
| sebras2 | kens: :) alright, then I'll stay clear of fuzzing for some time. | 12:57.29 |
| kens | Oh I don't mind if you fuzz MuPDF, just don't start on Ghostscript :-) | 12:57.47 |
| sebras2 | kens: how about jbig2dec? that would only affect henrys and possibly shelley..? >;-) | 12:58.26 |
| kens | FIne by me :-D | 12:58.36 |
| | Damn, bitten by evaluation order. Add more parentheses | 13:01.49 |
| tor7 | kens: hmm, interesting pdfwrite conversion I spotted here when cooking up a test file with nested clips | 13:54.06 |
| kens | :-( | 13:54.19 |
| | If it has a form it may do strange things | 13:54.32 |
| tor7 | ... clip ... gsave ... clip ... draw grestore draw | 13:54.48 |
| kens | OK | 13:55.02 |
| | I'm fairly certain we deal with that, its not terribly uncommon | 13:55.26 |
| tor7 | turns into: ... clip clip draw grestore clip (first one repeated) draw grestore | 13:55.26 |
| | the right results, but unexpected in duplicating the clip path | 13:55.40 |
| kens | SHouldn't one of those be a gsave ? | 13:55.45 |
| | tor7 If the result looks OK I won't worry abou tit | 13:55.55 |
| tor7 | gsave clip gsave clip draw grestore draw grestore - full input | 13:56.06 |
| | gsave clip clip draw grestore clip draw grestore - full output | 13:56.17 |
| | kens: yeah, but I was hoping to recreate the original sequence of operators as pdf by cheating with pdfwrite :) | 13:56.45 |
| kens | That looks bad, unbalanced save/restore | 13:56.47 |
| | tor7 that's a really bad plan ;-) | 13:57.01 |
| tor7 | sorry, gsave clip clip draw grestore gsave clip draw grestore | 13:57.09 |
| kens | Ah now I'm happier | 13:57.16 |
| tor7 | kens: for simple cases like this I would've hoped it might work :) | 13:57.32 |
| | still, now I can hack the pdf file but first I ought to get even this case working | 13:57.44 |
| | half of the clip masks are "inverted" in my opengl device :( | 13:57.56 |
| kens | Given the nightmare that is pdfwrite, I'm just happy if the result looks OK | 13:57.56 |
| tor7 | Robin_Watts: I think a mutool wrap command to take a command stream and pack it up in a pdf file (with the base14 fonts predefined as resources) would be awfully sweet to have | 14:03.36 |
| | but. must. not. procrastinate. more. | 14:03.59 |
| Robin_Watts | tor7: A tool to insert a command stream into a PDF file as a page, I could see. | 14:04.27 |
| | And then we'd "just" need an empty file to start from. | 14:04.44 |
| tor7 | Robin_Watts: yeah. basically take a raw command stream text file and wrap it up as a page | 14:04.48 |
| | an empty file to start from would be easily templated | 14:05.03 |
| | I could easily script something up with bash and mutool clean, but a one stop shop would be nicer | 14:05.36 |
| Robin_Watts | must not enable tor7's procrastination. | 14:06.55 |
| | :) | 14:07.00 |
| kens | chrisl for the logs, the whole usage of Metrics/Metrics2 seems to be broken in at least some senses. If I limit the currentpoint adjustment to fonts where WMode == 1 then 3 files improve (16-09.ps, 093-01.ps and Bug687614.ps) but another one gets worse (16-03.ps). | 14:31.30 |
| | Rendering seems to be incorrect when we have a WMode 0 font which has Metrics, and the glyphy Metrics are the 2 or 4 element forms. Single numbers work | 14:32.12 |
| | WMode 1 rendering also works | 14:32.18 |
| | But it always has the 4 element form anyway (Metrics2). | 14:32.39 |
| chrisl | kens: just back | 14:33.03 |
| kens | So tomorrow I'm going to start with the CET files and see if I can figure out what pdfwrite *should* be doing | 14:33.04 |
| | oh welcome back | 14:33.08 |
| chrisl | It's very unclear what that code is trying to do - it looks a bit like "I tried lots of stuff, and this seems to work for the tests I've got" | 14:34.18 |
| kens | You mena the pdfwrite code ? I'm inclined to agree | 14:34.35 |
| | But I think at least some of its problems may be that the interpreter isn't calling setcachedevice2 witrh the correct values, when Metrics has the 2 or 4 element form | 14:35.18 |
| | Obviously that's nothing to do with the WMode 1 case | 14:35.36 |
| chrisl | Yes, the pdfwrite stuff. I'll need to read up, there's a lot of strange stuff going on around the Metrics(2) stuff, that I don't remember very well | 14:36.13 |
| kens | Yeah. I htink I may end up ripping up the current code in the pdfwrite case and rewriting it. | 14:36.40 |
| | Having said that, I still don't understand the 2 test cases, but maybe I will after I work through the (simpler) CET tests | 14:37.20 |
| chrisl | Well, the other point is, (some of?) that code might be remaining hacks from before when pdfwrite was changed to handle the cdevproc | 14:37.55 |
| kens | Its possible of course. | 14:38.17 |
| | The good thing about the CET tests is that they cover WMode 0 and 1, and the fonts are much easier to handle than complex rotated type 42 | 14:38.57 |
| chrisl | Indeed | 14:39.44 |
| kens | Robin_Watts : am I misreading your openjpeg change, or did you put openjpeg at the same level as gs and Resource, rather than under gs ? | 14:47.45 |
| | We also still seem to have jasper in there | 14:48.55 |
| henrys | meeting time in a few minutes | 14:52.13 |
| Robin_Watts | kens: It's under gs. | 14:54.12 |
| kens | Hmmm.... | 14:54.24 |
| | Guess I cut and pasted it wrong then | 14:55.19 |
| henrys | mupdfer's: i added an item to the agenda you may have missed under other - ray's point about JNI and GPL. | 15:01.26 |
| mvrhel_laptop | I don't really have anything today for mupdf meeting. I am hoping to wrap up knockout transparency in gs this week and then finally get back to mupdf | 15:03.22 |
| Robin_Watts | henrys: Can you expand on rays point ? | 15:03.46 |
| henrys | Robin_Watts: yes is JNI binding like a DLL gpl wise or is it like static binding with a library (not allowed) | 15:04.35 |
| tor7 | henrys: yeah, I haven't seen anything ray has said (ghostbot was down most of the weekend it seems) | 15:04.40 |
| henrys | tor7:it is in the live agenda document under "other" | 15:05.04 |
| Robin_Watts | JNI bindings on MuPDF merely make MuPDF accessible direct from java. | 15:05.23 |
| tor7 | I can see the bullet point, but no discussion or details | 15:05.38 |
| henrys | mvrhel_laptop: I did want to talk about mobile printing | 15:05.54 |
| mvrhel_laptop | oh ok | 15:06.02 |
| Robin_Watts | For people to call mupdf under android they have to write their own jni bindings at some point. | 15:06.25 |
| henrys | Robin_Watts: okay so I use the bindings in my app do I have to publish my code or not? | 15:06.40 |
| tor7 | I don't think JNI would be any different to shared library linking, but if we ship the JNI bindings ourselves, the bindings would usually be statically linked or however java classes are bundled in an app | 15:06.40 |
| Robin_Watts | our app has them already for example, but they are app specific ones. | 15:06.45 |
| tor7 | so with robin's new JNI bindings, that would be linking to/using GPL'd java code as well as dynamically linking to our C library | 15:07.33 |
| Robin_Watts | ALL uses of native code under android have mupdf in the form of a shared library, and jni is just how you call into that lib. | 15:07.51 |
| | so us having new JNI bindings is no different to the existing android situation. | 15:08.15 |
| | If you have an app that loads a GNU GPL'd DLL and calls into it, that app has to be GNU GPL too, right? | 15:09.12 |
| chrisl | GPLv3. yes | 15:09.54 |
| Robin_Watts | Otherwise we'd have lots of people using gswin32.dll in their windows app, without needing a commercial license. | 15:09.59 |
| henrys | Robin_Watts: well I believe shared libraries are still fuzzy. | 15:10.05 |
| Robin_Watts | Well, then android falls into that same fuzzy area. | 15:10.18 |
| henrys | I didn't understand you were always going to a shared library and I don't think ray thought that either. | 15:10.52 |
| tor7 | AIUI, linking against GPL code is viral, both shared and static libraries | 15:11.12 |
| paulgardiner | JNI is mentioned here: http://vark.me.uk/spanners.381 | 15:12.07 |
| | ... although I'm yet to make out if it relates to our case | 15:12.24 |
| | Sorry wrong link | 15:12.37 |
| mvrhel_laptop | I was wondering about that | 15:12.44 |
| Robin_Watts | henrys: Android apps are APKs, which are zip files that contain java code in .class files, and any .so's required. | 15:12.51 |
| paulgardiner | http://www.gnu.org/licenses/gpl-faq.html | 15:12.56 |
| mvrhel_laptop | ok. that clearly is in line with tor7 's comment | 15:13.43 |
| tor7 | lawyers debate the issue hotly though, whether or not linking constitutes creating a derived work | 15:14.10 |
| sebras2 | tor7: if GPL code is not viral for dynamic/static libraries, then what is the point of LGPL..? | 15:14.48 |
| tor7 | LGPL exists for creating libraries that are "allowed" to be used commercially, so I'm leaning towards the stricter GPL interpretation with regards to linking | 15:15.02 |
| | sebras2: exactly. | 15:15.18 |
| mvrhel_laptop | and it has the standard end-run that some ghostscript dependent software does which is require separate downloads of gs and their application | 15:15.28 |
| | henrys: I just found out I have to run daughter to school. wife is out running and has not gotten back... | 15:16.01 |
| | i will bbiab | 15:16.11 |
| henrys | okay | 15:16.13 |
| sebras2 | tor7: well, this is the intent of the licenses as I understand them, then we have unreliable lawyers how do crazy stuff. :) | 15:16.25 |
| tor7 | sebras2: yes. the intent of the GPL (in light of the existence of an LGPL) is pretty clear, IMO. | 15:17.01 |
| sebras2 | tor7: but then this means that anyone using mupdf in the android app will have to make their app GPLv3..? | 15:17.02 |
| | unless they have a commercial license of course. | 15:17.22 |
| tor7 | sebras2: yes, it does. at least I hope it does! | 15:17.23 |
| henrys | so there is not "exec" call on android? | 15:18.38 |
| | s/not/no | 15:18.49 |
| Robin_Watts | henrys: Pass. | 15:19.16 |
| paulgardiner | As mvrhel_laptop pointed out, the FAQ seems pretty clear on the issue | 15:19.27 |
| tor7 | henrys: I think there's an equivalent of calling a separate "Activity" or whatnot | 15:19.32 |
| | like the edroidbookreader plugin guys robin has been talking to are doing | 15:19.44 |
| henrys | so unlike the desktop there is no way to use mupdf and not be GPL | 15:19.52 |
| sebras2 | correct me if I'm wrong, but I believe that there is some kind of way to ask android itself, please handle this file. probably with a MIME-type or something. doesn't mupdf depend on this for handlign .pdf-files..? | 15:20.12 |
| Robin_Watts | sebras2: Driving things by "Intents", yes. | 15:20.28 |
| sebras2 | ok, and you refer to another apps intents how..?\ | 15:20.52 |
| henrys | tor7:okay so separate activity would be like exec and not subject to the GPL virus | 15:20.59 |
| sebras2 | by string? | 15:21.03 |
| Robin_Watts | henrys: yes. | 15:21.19 |
| henrys | anyway now that's beaten to death, anything else for the mupdf meeting? | 15:21.32 |
| paulgardiner | sebras2: that's a good point. Thirdparty apps may be able to make use of our library via our app. | 15:21.35 |
| Robin_Watts | I believe some people have wrapped mupdf into a separate app, so that people can say "hey you over there, convert this PDF to a bitmap for me". | 15:21.49 |
| tor7 | henrys: I believe so, if they're not calling our functions directly but going via some OS-mediated in-between protocol | 15:21.51 |
| | like what robin just said | 15:22.06 |
| Robin_Watts | and I think people have been in touch with Miles about this and discussed it, and he's given them the OK. | 15:22.24 |
| | Separate optional downloads etc. | 15:22.38 |
| henrys | I didn't have anything else for the meeting, except mobile printing and I wanted to wait for michael. | 15:24.28 |
| tor7 | henrys: I have stencil buffered clipping almost working with the opengl device, it just needs a lot more debugging but it looks like my approach is going to work | 15:25.36 |
| henrys | tor7:great news any sense of performance improvement? | 15:26.09 |
| tor7 | it's bending my mind a bit too hard figuring out how to juggle the stencil function and state machine | 15:26.10 |
| Robin_Watts | I've solved some hangs etc in MuPDF, but nothing earthshattering to report. Except to prod people to look at the JNI stuff. | 15:26.20 |
| tor7 | henrys: image heavy pdf files seem quite a bit faster | 15:26.26 |
| | which is pretty much what we expect | 15:26.55 |
| paulgardiner | henrys: I'm continuing with the iOS enhancements, currently adding partial update | 15:27.29 |
| henrys | I hope you guys can stick around for the mobile print stuff. We should all talk about it. | 15:27.51 |
| tor7 | paulgardiner: have you added link following yet? | 15:28.30 |
| paulgardiner | tor7: No. Only just noticed that it's not already there. Will look at that soon | 15:29.09 |
| henrys | paulgardiner: is it more like porting or new development, trying to get a sense of what we'll need to maintain all these platforms. | 15:29.40 |
| tor7 | sebras2: your branch with inline form editing, how is that looking? on pause until you get back to europe? | 15:29.57 |
| sebras2 | tor7: most likely, yes. | 15:30.20 |
| | tor7: Is that a problem? | 15:30.29 |
| tor7 | sebras2: no, but it would be nice to have it before it rots too much :) | 15:30.42 |
| paulgardiner | henrys: I'd say closer to new development. I'm borowing things here and there from Android, but generally the OSes work very differently | 15:30.54 |
| tor7 | henrys: mobile printing, from the ios app, I guess means calling airprint somehow? | 15:30.58 |
| sebras2 | tor7: if I get bored in Shanghai (yes, that is a probability actually!) then I could give that branch prio over fiddling around with gstreamer. | 15:31.12 |
| henrys | tor7:yes I thought ray was doing something with AirPrint and ghostscript - I sent him my iPad so I assume it will be the same ... | 15:32.38 |
| | but the mobile printing thing seems to need discussion. We now have a marketing piece where mupdf connect to a printer running ghostscript. What are we talking about here, mupdf can ftp a pdf to the printer? | 15:35.49 |
| tor7 | don't ask me :) | 15:36.31 |
| paulgardiner_ | I fell of the internet for a moment there | 15:37.01 |
| henrys | that's what I wanted to talk to mvrhel_laptop about. | 15:37.45 |
| Robin_Watts | henrys: Why ftp ? | 15:37.50 |
| | Uploading a file using http is probably much easier. | 15:38.17 |
| | and doing that with curl etc is dead easy. | 15:38.27 |
| henrys | why are we selling that as a product is the question? | 15:38.39 |
| Robin_Watts | henrys: is that really what the marketing piece says? | 15:39.07 |
| paulgardiner | henrys: you mentioned AirPrint to me at the meeting. I haven't looked at it yet, but I could up the priority on that if you like. On the other hand, if Ray is looking at it, it may be best to wait to see what he gets up to. | 15:39.25 |
| rayjj | henrys: yes, I am going to get Bonjour up on the Raspberry Pi and see if I can get it to pretend to be a printer | 15:39.29 |
| Robin_Watts | If it's the thing that Miles was waving it at the meeting, I was interpretting that much more as "mupdf can output stuff that a printer using gs can print" | 15:40.03 |
| rayjj | henrys: what we run to handle the PDF that comes over can be gs or mupdf | 15:40.06 |
| | Robin_Watts: that doesn't make sense to me. | 15:40.31 |
| | mupdf can output stuff ??? | 15:40.41 |
| Robin_Watts | rayjj: Yes. Load a PDF, fill in the form fields, save it out to be printed. | 15:40.56 |
| henrys | Robin_Watts: if you had gs on the printer presumably you'd send pdf. | 15:41.02 |
| rayjj | oh, form filling. That makes sense | 15:41.11 |
| tor7 | getting the ios mupdf app to print using airprint, and then having gs + bonjour accepting jobs on a raspberry pie, would be a way to make the graphic in our pamphlets come true | 15:41.18 |
| henrys | Robin_Watts: okay forms, that makes sense. | 15:41.36 |
| tor7 | I believe we should not conflate supporting airprint for incoming jobs, and creating print jobs from mupdf apps | 15:42.06 |
| rayjj | tor7: making our marketing literature be true is much more than we usually do ;-) | 15:42.23 |
| Robin_Watts | If this is the thing that Miles was waving around it was just a triangular diagram with arrows between cloud, printers and devices. | 15:43.00 |
| | And I think it was just intended to show that we work (and interwork) between all the spaces. | 15:43.14 |
| | I don't think anyone is going to try to hold us to any given product based upon it. | 15:43.26 |
| | but if they did, we could knock something up without too much of a problem, I think. | 15:43.41 |
| henrys | The big disconnect is I think most customers thing of mobile printing as driverless printing, I can now print from my app with mupdf in some way and this not so at all. | 15:45.08 |
| | s/this/that | 15:45.22 |
| Robin_Watts | henrys: but we CAN print from mupdf. | 15:45.41 |
| henrys | Robin_Watts: but first you have to have a PDF | 15:45.58 |
| Robin_Watts | Right. | 15:46.09 |
| | So you're saying I need to finish mupdfwrite, yeah? :) | 15:46.37 |
| ray_laptop | henrys: AirPrint does send PDF's, so I guess any app that prints via AirPrint has the ability to generate PDF's via iOS something. Whether you call it a "driver" or not | 15:47.15 |
| henrys | If I have a PDF I don't need mupdf because I can "ftp" it to the printer. It's like a comedy skit | 15:47.34 |
| ray_laptop | Robin_Watts: well, you can generate a pdf-image file like a lot of scanner apps do | 15:47.44 |
| henrys | ray_laptop: I agree | 15:47.47 |
| | paulgardiner: is iOS printing using Quartz2d like mac os x? | 15:48.19 |
| Robin_Watts | henrys: Again, it depends if you read the marketing piece as "MuPDF ENABLES this path" or "MuPDF can make use of this path" | 15:48.43 |
| paulgardiner | henrys: Sorry, don't know. Really haven't looked at it at all yet. | 15:49.02 |
| henrys | mopria is pushing cups or they call it printer working group raster which I assume is cups http://www.mopria.org/Home.aspx | 15:50.59 |
| | and something called M-PCL | 15:51.15 |
| paulgardiner | If it's PDF based, I'd quess that adding AirPrint to the iOS app would be no harder than the addtion of Google Cloud Print to the Android app was | 15:51.18 |
| ray_laptop | mupdf enables the part where a PDF from the cloud gets annotated or form-filled, then spit back out | 15:51.37 |
| | back to the cloud or to a printer | 15:52.21 |
| Robin_Watts | henrys: Is there some "promise" made by this marketing piece that you feel we can't live up to? | 15:53.01 |
| henrys | Robin_Watts: I just want to clarify what we are saying when we draw a line labeled mupdf from a phone to a printer | 15:54.16 |
| Robin_Watts | henrys: Well, mupdf IS used in certain libraries from commercial customers that are shipped to app manufacturers specifically for them to be able to print from embedded devices. | 15:55.14 |
| ray_laptop | henrys: in some scenarios, if the printer needs raster data, mupdf can render a PDF from the cloud to enable printing to that class of printer | 15:57.15 |
| Robin_Watts | ray_laptop: We can produce PWG or PCL (mono) too. | 15:57.37 |
| ray_laptop | Robin_Watts: was PWG the cloud raster format ? | 15:58.05 |
| Robin_Watts | PWG is cups format. | 15:58.16 |
| | and it is one of the formats that the cloud accepts, yes. | 15:58.26 |
| ray_laptop | which is one of the common options for IPP | 15:58.45 |
| henrys | yes if it is not a pdf printer, I get it⦠but if PDF is the PDL we are selling "cat" | 15:58.58 |
| | which I don't get. | 15:59.12 |
| ray_laptop | "cat" ??? | 16:00.20 |
| | as in unix cat ? | 16:00.35 |
| henrys | the unix command. | 16:00.36 |
| sebras2 | henrys: if someone is willing to pay for "cat" then why not...? :) | 16:00.49 |
| paulgardiner | henrys: Right. I understand what you are pointing out now. | 16:00.55 |
| ray_laptop | henrys: well, yes, unless you annotated on the device and want to print that | 16:01.18 |
| Robin_Watts | henrys: Can you give a pointer to the marketing thing you are talking about please? | 16:01.36 |
| ray_laptop | but lots of people open a PDF in a viewer (AR) then print it | 16:01.44 |
| Robin_Watts | Is it the sheet that Miles handed out at the meeting? | 16:01.46 |
| henrys | I wanted to discuss it with mvrhel_laptop because he and miles put it together in Japan, maybe there is something I don't understand. I don't have a copy of it now. | 16:02.36 |
| Robin_Watts | henrys: It's the triangular diagram, right? | 16:02.52 |
| henrys | onto ghostscript until mvrhel_laptop returns | 16:02.57 |
| Robin_Watts | AIUI we're selling the things at the corners of the triangle, not the things on the edges. | 16:03.10 |
| ray_laptop | so mupdf is providing the viewing capability, and then also lets you print it if you want a hardcopy. True, your browser might be able to send a PDF to the printer as well, but it's not as nice of a viewer app | 16:03.14 |
| henrys | chrisl: sorry I didn't get to urw but will get to it this week. | 16:03.55 |
| chrisl | henrys: okay, I haven't been nagged by the open source user folks about it, so if they pipe up, I'll fend the, off | 16:04.45 |
| | them | 16:04.50 |
| henrys | chrisl: I'm doubting urw will lift a finger but we'll see. | 16:05.31 |
| chrisl | henrys: Well, it is a regression, so...... | 16:06.13 |
| henrys | chrisl: I agree we'll see. | 16:06.55 |
| | ray_laptop: you were going to contact 801? | 16:07.14 |
| | ray_laptop: I can do it if you are busy. | 16:07.29 |
| ray_laptop | oh, cr*p. I was working on cust 532's problems and it slipped my mind | 16:07.45 |
| | I'll do that now. Sorry. | 16:07.57 |
| henrys | ray_laptop: thanks. | 16:08.20 |
| Robin_Watts | ray_laptop: Have you heard anything more about their new printer yet ? | 16:08.25 |
| henrys | Robin_Watts: should we discuss malloc and lcms? | 16:09.26 |
| Robin_Watts | malloc and openjpeg ? | 16:09.40 |
| ray_laptop | Robin_Watts: cust 532's ? | 16:09.57 |
| Robin_Watts | ray_laptop: yes. | 16:10.07 |
| ray_laptop | Robin_Watts: all I heard is that they introduced "improvements" in their device and it produces white lines in images under certain cases. | 16:10.48 |
| henrys | Robin_Watts: maybe I misread something I thought there was some problem using gs allocation in lcms. | 16:10.55 |
| Robin_Watts | henrys: Oh, OK. We have 2 issues here there. | 16:11.15 |
| | lcms is fine if used as a statically linked lib. | 16:11.42 |
| ray_laptop | Robin_Watts: AIUI, these improvements were intended to speed things up on images. Len asked me to look into it, but that they basically "own" the problem | 16:11.47 |
| Robin_Watts | Actually, even that's not true. | 16:12.28 |
| | lcms is fine if we're the only caller of it. | 16:12.37 |
| henrys | and a related issue do we need to lock the actual malloc in heap_alloc_bytes or just the updates to the bookkeeping structures. Windows already locks mallocs I think linux does TLS. | 16:12.50 |
| | ? | 16:12.53 |
| mvrhel_laptop | ugh finally back. traffic was horrific. | 16:13.13 |
| ray_laptop | henrys: we shouldn't need to lock malloc | 16:13.30 |
| Robin_Watts | If someone builds gs + some code that calls lcms, then all the other callers calls will get the gs allocation functions and will probably crash. | 16:13.30 |
| | The correct thing to do is to fix lcms, but that's an API change. | 16:13.50 |
| chrisl | Robin_Watts: so the lcms one we're going to "solve" by leaving out the gs memory calls when using it "shared" - I'll get to that this week. | 16:14.04 |
| Robin_Watts | When we mentioned this at the meeting, mvrhel_laptop was going to bring it up with Marti when he saw him in November. | 16:14.23 |
| | chrisl: That's only a partial solution. | 16:14.29 |
| ray_laptop | Robin_Watts: so this is an app calling lcms after calling gs (which sets the allocator callbacks) ? | 16:14.32 |
| chrisl | Robin_Watts: hence "solve" being in quotes | 16:14.53 |
| Robin_Watts | ray_laptop: After or at the same time. | 16:14.56 |
| | chrisl: An app that statically links with gs and also calls lcms will still fail then. | 16:15.22 |
| henrys | mvrhel_laptop: could you have a look at the logs about mobile printing? | 16:15.24 |
| ray_laptop | Robin_Watts: right, concurrently in a different thread | 16:15.26 |
| chrisl | Robin_Watts: even if both just let lcms use malloc/free? | 16:15.52 |
| henrys | kens:anything for the meeting? | 16:15.52 |
| mvrhel_laptop | henrys: so the mobile device to printer path in that marketing sheet is supposed to be something like airprint | 16:15.53 |
| Robin_Watts | ideally we want to 'hide' the lcms entrypoints from everyone except gs in a static link. And that's a bugger to do portably. | 16:15.56 |
| | chrisl: If both just let lcms use malloc/free we're fine. | 16:16.08 |
| mvrhel_laptop | whereby artifex is supplying the viewer on the mobile device. | 16:16.13 |
| henrys | mvrhel_laptop: we are selling "cat" | 16:16.15 |
| Robin_Watts | If either one doesn't.... | 16:16.16 |
| mvrhel_laptop | and someone wants to print | 16:16.22 |
| | and they send it using what ever protocol to their local printer | 16:16.36 |
| Robin_Watts | ray_laptop: Right. | 16:16.39 |
| mvrhel_laptop | which could have gs embedded in it | 16:16.46 |
| chrisl | Robin_Watts: in the interim, just being able to say "we're not to blame" is a decent start - until lcms can be properly fixed | 16:16.55 |
| Robin_Watts | chrisl: Indeed. | 16:17.01 |
| mvrhel_laptop | Robin_Watts: I am not going to see Marti now | 16:17.29 |
| Robin_Watts | but our plan for getting it fixed probably needs to involve 'persuading' Marti. Possibly with a baseball bat with nails in. | 16:17.36 |
| mvrhel_laptop | the ICC meeting occurs when I am in Japan | 16:17.40 |
| Robin_Watts | mvrhel_laptop: Oh, crap. | 16:17.45 |
| mvrhel_laptop | I think so anyway | 16:17.52 |
| | let me double check the dates | 16:17.55 |
| Robin_Watts | OK, so the *second* problem of this ilk... | 16:18.12 |
| | malloc and openjpeg. | 16:18.21 |
| kens | henrys, nothign from me, I'm buried in CIDFonts | 16:18.23 |
| Robin_Watts | openjpeg routes all it's allocation through calls to opj_malloc/opj_free etc, but unfortunately these are just macros that end up calling malloc and free. | 16:18.34 |
| ray_laptop | so lcms needs a 'context' that maintains separate callbacks for each context, right ? | 16:18.38 |
| mvrhel_laptop | I am not even 100% sure he would be their anyway | 16:18.43 |
| Robin_Watts | ray_laptop: Absolutely. | 16:18.45 |
| | ray_laptop: And he's half heartedly added it, but in a broken way. | 16:19.13 |
| mvrhel_laptop | yes, the dates overlap | 16:19.15 |
| henrys | Robin_Watts: yes I think we have a bug about Luratech and openjpeg not using gs. | 16:19.21 |
| | using gs malloc that is. | 16:19.38 |
| Robin_Watts | henrys: bug 693339 ? | 16:19.50 |
| | I think openjpeg is the last criminal. | 16:20.02 |
| | I looked at openjpeg today to see if it would be easy to fix. | 16:21.13 |
| henrys | Robin_Watts: I did too, and I recall it being a pain in the ass but I don't remember the details. | 16:21.41 |
| Robin_Watts | and it's a trivial headerfile change to make openjpeg rely on user supplied opj_malloc/free calls. | 16:21.46 |
| henrys | Robin_Watts: I thought something else was messed up with it. | 16:22.07 |
| Robin_Watts | BUT... there is no way to get a gs_memory_t * or a fz_context * to those calls. | 16:22.08 |
| mvrhel_laptop | henrys: so the purpose of the marketing piece was to show that Artifex has solutions for Mobile, Cloud and Printers | 16:22.16 |
| Robin_Watts | mvrhel_laptop: Right. We're selling the corners, not the edges. | 16:22.30 |
| mvrhel_laptop | right | 16:22.34 |
| | That has been Miles' point at the meetings. | 16:23.02 |
| Robin_Watts | and we can't get a gs_memory_t etc to those things without changing api's all the way through openjpeg. | 16:23.21 |
| mvrhel_laptop | Now it turns out that some of the customers (or at least one of them) had no clue about Airprint and wanted help with that | 16:23.39 |
| henrys | Robin_Watts: yes now I remember the pain in the ass part. | 16:23.40 |
| Robin_Watts | For gs we might be able to fix it by using a static, and a lock around every opj_call | 16:23.44 |
| mvrhel_laptop | that is what prompted that in the meeting | 16:23.48 |
| Robin_Watts | For mupdf that's harder as we go to some lengths to be threading agnostic. | 16:24.06 |
| mvrhel_laptop | if we had some way to show a simple demo doing it, it would be a useful sales tool | 16:24.15 |
| chrisl | Robin_Watts: what about if we make it a bug, assign it to Shelly, and he can sound the OPJ devs about fixing it properly? | 16:24.18 |
| henrys | mvrhel_laptop: I just see a pdf being pushed around. | 16:24.29 |
| mvrhel_laptop | yes | 16:24.35 |
| | I agree | 16:24.37 |
| Robin_Watts | chrisl: Would they accept a wholesale change to their API? | 16:24.39 |
| mvrhel_laptop | but to the customer they see a solution to their problme | 16:25.01 |
| chrisl | Robin_Watts: I don't know, but they've already taken a change that breaks the ABI (which was surprising). That's why I think it's at least worth asking | 16:25.39 |
| henrys | until an engineer tells them they don't have a problem. | 16:25.46 |
| Robin_Watts | chrisl: OK, I'm more than happy to create a bug with the description in and lob it at shelly. | 16:26.04 |
| | henrys: If you want to print from an embedded device to a printer, stage 1 is to do a print preview on the device. | 16:26.48 |
| mvrhel_laptop | henrys: anyway that was one customer who for what ever reason was unable to read a spec about Airprint and get it working | 16:26.49 |
| chrisl | Robin_Watts: I figure he has some kind of relationship there now, and he can always punt it back to us if they're not keen | 16:26.57 |
| mvrhel_laptop | But it would be a big customer | 16:27.05 |
| Robin_Watts | chrisl: Sure. I'll do that then unless henrys says different. | 16:27.13 |
| mvrhel_laptop | and if it is easy to do then why not do it | 16:27.14 |
| henrys | mvrhel_laptop: I'm really just trying to flesh out "mobile printing" and seeing where we have opportunities. | 16:28.11 |
| ray_laptop | henrys: message to cust 801 sent | 16:28.33 |
| mvrhel_laptop | henrys: right. I would like to review what is going on in this space myself. it really is what the customers are focused upon. they all want their own app to do it too | 16:29.44 |
| henrys | mvrhel_laptop: possibly on iOS mupdf could be a printer driver - if the printing framework is the same as the mac. | 16:29.47 |
| | mupdf would produce the printer format postscript or pwg raster or the like. | 16:30.21 |
| mvrhel_laptop | right | 16:30.29 |
| henrys | there still are many printers not doing pdf natively. | 16:31.04 |
| mvrhel_laptop | absolutely. | 16:31.25 |
| henrys | Let's not go over the 1/2 hour but I'll be around if anyone wants to talk. | 16:31.57 |
| Robin_Watts | henrys: It would be possible to build a printer driver out of mupdf even if you didn't get a PDF in. | 16:32.32 |
| marcosw | ray_laptop: I can log into peeved and have added peeved.ghostscript.com to bind. Shall I set it up as a cluster node? | 16:32.52 |
| ray_laptop | Robin_Watts: what *would* be the input ? | 16:32.58 |
| henrys | Robin_Watts: you mean with graphics calls? | 16:33.07 |
| Robin_Watts | ray_laptop: You can open a device, and then do graphics calls to that device. | 16:33.18 |
| ray_laptop | marcosw: please do. Let me know if I need to do anything local | 16:33.22 |
| | Robin_Watts: I see -- just calling the mupdf lib as a graphics lib for an app | 16:33.43 |
| henrys | marcosw: if there are many more fuzzing problems can you turn off the email? | 16:33.45 |
| marcosw | henrys: that's it for fuzzing (at least for GhostPCL). | 16:34.09 |
| Robin_Watts | ray_laptop: Right. And we'd get preview from that. And PWG and PCL output. | 16:34.17 |
| | And if I finish pdfwrite/svgwrite, PDF and SVG too. | 16:34.32 |
| henrys | Robin_Watts: I assume that is what cairo does with it's clients, we've discussed getting that a bit more usable and documented. | 16:35.03 |
| | s/it's/its | 16:35.16 |
| | english | 16:35.17 |
| marcosw | ray_laptop: since I have sudo access and can run apt-get install I shouldn't need any help. | 16:35.20 |
| ray_laptop | marcosw: OK. And as I mentioned, you should have fast connection to peeves since they are both on the same subnet | 16:36.22 |
| Robin_Watts | henrys: Right. The JNI stuff should be a step towards that I hope. | 16:36.26 |
| ray_laptop | unfortunately, the TW cable router is only 100 not gigabit ethernet | 16:37.04 |
| marcosw | ray_laptop: yes, I'll rsync the tests and tests_private repositories over from peeves instead of installing them from casper. | 16:37.11 |
| ray_laptop | I am thinking about getting a gigabit switch for the local subnet and only go to the router for "outside" | 16:37.45 |
| | but that probably won't be today | 16:38.30 |
| marcosw | I'm seeing rsync speeds of 11.1 MB/s between peeves and peeved, so pretty much at the limit of 100baseT | 16:44.31 |
| | still better than dowloading from casper :-) | 16:44.52 |
| ray_laptop | marcosw: yeah. my downlink is 7 Mbits | 16:45.21 |
| Robin_Watts | marcosw: I put a new patch up that should fix the blue tiger thing thing. | 16:47.03 |
| | on bug 693070. | 16:47.22 |
| marcosw | Robin_Watts: yes, saw that. Already downloaded and it does work. I've run the files and am now comparing the subset that doesn't produce an error. | 16:48.04 |
| Robin_Watts | Ah, perfect, thanks. | 16:48.16 |
| | What proportion gives errors? | 16:51.39 |
| marcosw | ~75% | 16:51.53 |
| ghostbot | 0.75 | 16:51.53 |
| kens | ghostbot! ? | 16:52.05 |
| marcosw | that was weird | 16:52.09 |
| Robin_Watts | crumbs, that's huge. | 16:52.10 |
| | ~10*20+30*4 | 16:52.25 |
| ghostbot | 320 | 16:52.25 |
| marcosw | it's all the same error message, so presumably one bug :-) | 16:52.29 |
| Robin_Watts | ghostbot does sums! | 16:52.43 |
| marcosw | great, now I don't need to fire up the google machine to do maths anymore. | 16:52.56 |
| | sqrt(12) | 16:53.00 |
| Robin_Watts | ~sqrt(12) | 16:53.08 |
| | ~sqr(12) | 16:53.14 |
| marcosw | 12+2 | 16:53.18 |
| | ~12+2 | 16:53.21 |
| ghostbot | 14 | 16:53.21 |
| marcosw | ~sin(90) | 16:53.28 |
| | okay, maybe I still need google. | 16:53.36 |
| kens | OK off to cook, goodnight all | 16:57.37 |
| ray_laptop | what mac osx doesn't have dc ? | 17:02.32 |
| | I *know* linux does (but bc is a lot easier to use) | 17:04.27 |
| henrys | oh good the government is shutdown so IRS is going to stop collecting until we open again ;-) ? | 17:10.55 |
| ray_laptop | henrys: NPR said that one of the things that would be shutdown is IRS audits | 17:11.51 |
| | just so long as they don't pay those yahoos in congress | 17:14.58 |
| | in CA, when they don't pass a budget on time the legislatures have their pay docked. | 17:15.43 |
| Robin_Watts | ray_laptop: Sadly, congressmen continue to be paid. | 17:15.57 |
| ray_laptop | oh, it's just their staff that don't get paid? | 17:16.22 |
| | I hadn't looked into that | 17:16.31 |
| | Robin_Watts: apparently a lot of outrage on the web today about that | 17:17.30 |
| Robin_Watts | ray_laptop: Indeed. | 17:18.17 |
| henrys | so we've shutdown everything except defense and entitlements - so 5% of the government is closed | 17:27.44 |
| Robin_Watts | bah. ray just dropped off. | 18:29.35 |
| chrisl | He probably saw the mail from Len, and ran screaming into the hills...... | 18:30.31 |
| Robin_Watts | 6th gen is 600dpi mono? | 18:30.44 |
| | or color? | 18:30.48 |
| chrisl | I'm not sure, sorry | 18:31.07 |
| Robin_Watts | http://plasmasturm.org/log/6debug/ | 19:24.07 |
| mvrhel_laptop | Robin_Watts: so are you seeing the same issues with their file that the trans. on the one page is the timing issue? | 19:57.24 |
| Robin_Watts | mvrhel_laptop: 532? | 23:07.12 |
| | I haven't tried the new simulator yet, but on the old one the transparency was a big hunka time. | 23:08.05 |
| | Now, I put some optimisations in for 1bpp output. | 23:08.30 |
| | and those won't be being triggered cos they want 2bpp output, so I may just redo the optimisations for that case. | 23:08.53 |
| mvrhel_laptop | Robin_Watts: oh I thought you had previously said on the file that transparency was only on page 2 and was a tiny bit of time esp. since everything is in gray | 23:26.17 |
| | but perhaps I was mistaken Robin_Watts | 23:26.30 |
| Robin_Watts | Indeed, page 2 is the only transparent bit. | 23:26.38 |
| | and on the timings for the previous simulator, it was a fairly low percentage of time, partly cos it was going through code that I'd already optimised. | 23:27.22 |
| | For this target the time looks higher. | 23:27.33 |
| | possibly because it's not hitting the optimised cases. | 23:27.46 |
| mvrhel_laptop | i see | 23:27.48 |
| Robin_Watts | I've got the simulator downloaded now, so I'll give it a whirl in the morning. | 23:28.00 |
| | page 2 in this set is 6.6 seconds, compared to 2.2 ish for the other pages. | 23:28.44 |
| mvrhel_laptop | ok so I have some progressions and some areas that I see are wrong (still) with the clusterpush | 23:35.07 |
| | one isolated now... | 23:35.38 |
| | Forward 1 day (to 2013/10/02)>>> | |
IRC Logs