| | <<<Back 1 day (to 2013/05/06) | 2013/05/07 |
| kens | Oh dear. Ray's commit seems to have broken the build | 07:20.30 |
| | Looks like a typo in clist_render_rectangle, save_page_neutral ought to be save_pageneutralcolor | 07:21.59 |
| sebras | tor8: I have been contemplating doing field editing in the searchbar in the x11-viewer instead of doing it in the console. | 09:30.26 |
| Robin_Watts | nice. | 09:30.45 |
| sebras | tor8: one could argue that you'd lose unicode-capability then, but we already interpret the entered text incorrectly... | 09:30.49 |
| tor8 | would be a nice stop-gap until the gtk+ viewer is back on track | 09:31.01 |
| sebras | tor8: Robin_Watts: alright, I'll put some more effort into it then. :) | 09:31.29 |
| tor8 | or, you could whip me until I finish the gtk+ viewer :) | 09:31.50 |
| | I believe the most urgent burning fires have been put out now so I can focus on it at last. | 09:32.26 |
| | Robin_Watts: did you see my commits last night? | 09:32.38 |
| sebras | tor8: ok. well. there is no reason not to look into the x11-stuff anyway. ;) | 09:32.55 |
| sebras | might learn something... | 09:33.00 |
| tor8 | just how limited x11 is in terms of raw input and drawing text? ;) | 09:33.18 |
| Robin_Watts | tor8: I saw that they were there, I didn't look yet. | 09:34.51 |
| | I'm struggling with patterns in SVG at the moment. | 09:35.12 |
| sebras | tor8: exactly. | 10:31.15 |
| kens | Interesting snippet: | 11:09.50 |
| | http://www.theregister.co.uk/2013/05/07/windows_8_u_turn/ | 11:09.50 |
| | Anyone pay for FT access ? | 11:09.50 |
| chrisl_r61 | Sounds like the rumours were right, then | 11:12.37 |
| kens | Seems to be so | 11:17.20 |
| Robin_Watts | yeah, but all the start menu does is change to the metro screen. | 11:26.06 |
| | So you're getting a start button back, but losing the start menu. | 11:26.22 |
| chrisl_r61 | For now, until MS bow to further pressure...... | 11:26.58 |
| kens | they are saying you can boot to desktop | 11:28.52 |
| Robin_Watts | Windows Clasic Shell, gives the menu back in a sensible form. | 11:43.50 |
| | tor8: OK, so patches... | 11:46.31 |
| | UCDN/linked list/RTL/Fix formatting are all fine. | 11:46.47 |
| | the other two are still work in progresses, right? | 11:46.59 |
| tor8 | WIP is just something I wanted to test, the mesh patch subdiv is carried over from your branch | 11:47.31 |
| Robin_Watts | indeed. | 11:47.39 |
| | Did the android fixes get rolled in? | 11:48.00 |
| | no, so there will be another review for those in a mo. | 11:48.48 |
| tor8 | I haven't done anything with the android (except change the name of fz_analyze_text) from where I took over off your master | 11:48.52 |
| | Robin_Watts: I'll let you untangle the web of branches and push the commits :) | 11:50.43 |
| Robin_Watts | tor8: patches pushed | 12:07.26 |
| | tor8: Android fix commit up for review. | 12:07.42 |
| tor8 | Robin_Watts: "Android: Fix android build"? | 12:10.30 |
| Robin_Watts | tor8: yup. | 12:10.58 |
| tor8 | looks fine | 12:14.17 |
| Robin_Watts | ta. | 12:14.30 |
| sebras | tor8: oh, rtl! then my arabic friend will be impressed. :) | 12:22.54 |
| | well, he'll stop complaining... | 12:23.13 |
| tor8 | sebras: if you could get him to try it out and tell me what I've done wrong that'd be swell! | 12:23.29 |
| Robin_Watts | has nook! | 12:25.25 |
| sebras | tor8: if you can provide an .apk somehow, I might convince him to test it today... | 12:36.30 |
| | otherwise I'll build it myself tonight and ask him tomorrow. | 12:36.50 |
| tor8 | Robin_Watts: the glo nook? | 12:36.52 |
| Robin_Watts | tor8: No, a "nook simple touch" - they were selling them off for 30 quid, and I can root it to make it a generic android device and run the kindle app/mupdf on it. | 13:30.49 |
| tor8 | I wonder how that'll behave with e-ink | 13:31.43 |
| | that smooth scrolling stuff can't be good on e-ink devices | 13:31.59 |
| Robin_Watts | tor8: There is a multitouch hack, supposedly. | 13:32.06 |
| svip | Greetings; I am trying to convert a PDF to PDF on Windows, and I am having an issue with fonts. When I run without -sFONTPATH, it complains that it cannot find the fonts, and substitues it with a less than decent font; for instance ø becomes ³. When I do provide -sFONTPATH="C:\windows\fonts\", it doesn't complain, but it merely provides a single blank page in the resulting PDF. | 13:32.44 |
| | Why am I converting a PDF to PDF; because FastReports' PDF export is incapable of creating a PDF that can be read on iOS devices. | 13:33.09 |
| tor8 | sounds like FastReport's PDF export is not very good... | 13:34.08 |
| svip | Well, their PDFs work on all other devices. | 13:34.52 |
| | So I did not notice intially. | 13:34.57 |
| tor8 | svip: have you got a sample PDF somewhere I can download it? | 13:35.21 |
| svip | http://sviip.dk/report.pdf | 13:35.29 |
| tor8 | it's (sadly) all too common for software to print some pdf-lookalike garbage, check that it works in adobe and call it a day... | 13:37.17 |
| svip | Well, I did test it in FoxIt, Evince and on Android before doing that. | 13:38.44 |
| tor8 | one problem with that file is that it uses fonts by indexing their glyph numbers directly bypassing encoding tables, but does NOT embed them. that's a blatant violation of the spec. | 13:38.48 |
| | and if you get anything that resembles text out, it's probably only because the reader has access to exactly the same font file on system as was used by the creator | 13:39.20 |
| | mocking the P in PDF... | 13:39.39 |
| svip | Hmmm! | 13:39.48 |
| tor8 | if you can tell the pdf export to embed the fonts, I'm sure it'll work a lot better on iOS | 13:40.14 |
| svip | Ah. Hmm... I did disable embedded fonts. :S Why did I do that? | 13:40.28 |
| | I was probably drunk. | 13:40.34 |
| tor8 | smaller file size, probably | 13:40.42 |
| kens | THey are part of the Windows xtandard set, Arial and Tahoma | 13:40.42 |
| | So they will probably work on any WIndows machine | 13:41.09 |
| tor8 | lots of producers seem to treat the windows standard set as being always available... despite it not being the case... I wish they could at least use the proper font encoding mechanisms in PDF so that substitute fonts will work reliably. | 13:41.52 |
| kens | THought hte fonts are declare4d as CIDFont with a surpsising Fonttyep of 2 | 13:41.54 |
| | THey seem to be using Identity CMaps | 13:42.24 |
| tor8 | kens: Identity-H encoded CID fonts. same issue as last week. | 13:42.29 |
| kens | So CID = GID | 13:42.29 |
| | Fundamentally a file like this won't work at all with substitute fonts, so if you don't embed the fonts, its not going to work. | 13:43.06 |
| tor8 | svip: so in summary, it's broke because you didn't embed the fonts. it works on most viewers because they can find the windows fonts. ios doesn't ship with the windows fonts, so it doesn't work there. | 13:44.14 |
| kens | pdf.js gets quick upset about page 1 | 13:44.17 |
| svip | tor8: Indeed. And now I fixed it, by embedding the fonts. | 13:44.56 |
| kens | THe droid sans fallback seems to work OK in GS | 13:45.16 |
| tor8 | kens: the workaround from the bug fix last week works in MuPDF :) | 13:45.40 |
| kens | For me, using current code, the pdfwrite outptu works just fine with the DroidSans fallback font also | 13:46.31 |
| | svip which version of GS are you using ? | 13:46.38 |
| svip | The newest I found; 9.07 | 13:46.59 |
| | But I don't need it anymore. | 13:47.03 |
| kens | actually, when I say it 'works' I mean its legible | 13:47.06 |
| svip | With embedded fonts, it works. | 13:47.09 |
| henrys | kens:maybe we should bring up running all the tests with %d with marcosw, if you think there is potential for more problems. | 13:48.24 |
| kens | henrys there is certainly potentail for problems, this isn't a mode that pdfwrite normally gets run in | 13:48.48 |
| | But I'mnot sure how feasible it is for Marcos to run it that way | 13:49.14 |
| | chrisl ping | 13:49.57 |
| | or even chrisl_r61 | 13:50.16 |
| henrys | kens:yes the tests run to stdout and are md5'd. | 13:52.28 |
| kens | henrys are you sure about pdfwrite ? The files are run back through rendering devices for comparison I thought | 13:53.04 |
| henrys | oh that's right so he should be able to do it. | 13:53.29 |
| chrisl | kens: pong | 13:54.32 |
| kens | It seems possible, but I don't know what sort of havoc that would unleash, thre would be possibly hundreds of files produced | 13:54.33 |
| | chrisl got some build errors in contrib, relating to sprintf | 13:54.58 |
| | EG: | 13:55.08 |
| | ./contrib/japanese/gdevfmlbp.c:139: warning: pointer targets in passing argument 1 of 'sprintf' differ in signedness | 13:55.08 |
| | As long as you know, I'm happy to ignore it | 13:55.31 |
| chrisl | Erm, thought I fixed those - I'll check them | 13:55.44 |
| kens | Mayeb I missed an update | 13:55.55 |
| | I got 2 warnings in gdevfmlbp.c and 2 in gdevlpb3.c | 13:56.28 |
| chrisl | Hmm, that's confusing :-( | 13:59.19 |
| | kens: there shouldn't be warnings - gs_sprintf() takes a char * and the parameters are being cast to char *'s | 14:01.20 |
| kens | Well, I cna try updating again. | 14:01.40 |
| | could be signed/unsigned char its complaining about ? | 14:02.01 |
| | Not sure how they would get different default sign though | 14:02.35 |
| chrisl | Except I added an explicit cast to remove a warning | 14:02.40 |
| | So ./contrib/japanese/gdevfmlbp.c:139 looks like: gs_sprintf((char *)buff,"%d",x); | 14:03.25 |
| kens | buff is defined as unsigned char in my copy, and has no cast. | 14:03.47 |
| | So I guess I'm behind the times | 14:03.55 |
| chrisl | But all the changes went in one commit | 14:04.28 |
| kens | THis is what's in gdevfmlbp.c for me : | 14:05.04 |
| | static void goto_xy(FILE *prn_stream,int x,int y) | 14:05.04 |
| | { | 14:05.04 |
| | unsigned char buff[20]; | 14:05.04 |
| | unsigned char *p=buff; | 14:05.04 |
| | fputc(CEX,prn_stream); | 14:05.05 |
| | fputc('"',prn_stream); | 14:05.05 |
| | sprintf(buff,"%d",x); | 14:05.06 |
| | SO thats an sprintf of an unsigned char * | 14:05.23 |
| chrisl | Well, that's not what's in the commit | 14:06.18 |
| kens | Puzzling | 14:06.26 |
| | I'm about to commit a change, I'll have to update anyway, let me see if it changes. | 14:06.50 |
| chrisl | You can see here that I included those changes in the commit: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=e64ac4c83a4ae07dc15c4cacd7b60cba6294899a#patch48 | 14:07.19 |
| kens | Looks like I didn't have the sprintf changes | 14:07.43 |
| | WHich make sme wonder why I got the warnings.... | 14:07.51 |
| chrisl | Because they won't be there in master | 14:08.15 |
| kens | coffees | 14:13.08 |
| svip | tor8: Is Helvetica part of the ghostscript engine? | 14:36.37 |
| | In the sense, that I do not need to embed Helvetica? | 14:36.44 |
| | A site suggests that the base 14 fonts are built into most PostScript engines. | 14:37.07 |
| kens | Helvetica is one of the 'base 35' fonts | 14:37.12 |
| tor8 | svip: there are two issues here. | 14:37.13 |
| kens | But I woudl still recommend embedding *all* fonts | 14:37.30 |
| tor8 | there are the base 14 fonts in PDF in bold/italic/bolditalic variants | 14:37.31 |
| | but, they must be "simple fonts" in PDF speak | 14:37.57 |
| | in the file you linked, the fonts were "CID fonts" which must be embedded | 14:38.14 |
| | so even if the file is Helvetica (one of the base set) if it's done as a CID font it will not work | 14:38.38 |
| svip | I see. | 14:38.59 |
| tor8 | svip: Arial is an alias in the PDF spec for Helvetica (as in, it will use helvetica for arial as if it was a base font) | 14:39.23 |
| | but in the file you linked, the arial was a cid font... | 14:39.38 |
| svip | Thank you. | 14:47.15 |
| paulgardiner | I think this is ready to commit now: http://git.ghostscript.com/?p=user/paulg/ghostpdl.git;a=commitdiff;h=537705dca732dd44fce9e753a859e7cb77b38f64 | 14:47.15 |
| | Could someone give it the once over? | 14:47.47 |
| henrys | paulgardiner: maybe a future development would be to get rid of #ifdef METRO - we've tried to stay away from #defines per platform and instead use gp_* files. | 14:51.33 |
| kens | henrys this is for different vbersions of the same platofrm | 14:52.05 |
| | It like we use #ifdef WIN32 | 14:52.15 |
| henrys | yes I guess I think of rt as being an entirely separate beast but maybe that's not a good view. | 14:54.35 |
| paulgardiner | I was just going with the flow, but it would be nice to avoid the ifdefs. | 14:55.06 |
| henrys | I certainly wouldn't confuse iOS and macos x but maybe that's different | 14:55.08 |
| kens | At least some of the changes Paul has made would have been possible in earlier versions of Windows. We are still (for good reason) using old interfaces. | 14:55.17 |
| | henrys IOS and MacOS are really quite different, metro and win32 not so much | 14:55.40 |
| | The changes look OK to me paulgardiner, but I know nothing about windows 8 really. | 14:57.04 |
| paulgardiner | kens: nor me! :-) | 14:57.24 |
| mvrhel_laptop | good morning | 14:58.21 |
| paulgardiner | I guess the problem with using gp_ functions for minor OS differences is either you have lots of repeated code, or you have to invent a new set of lower-level interfaces | 14:58.27 |
| kens | Some of it we oucld get away with, but only by dropping support for older versions of Windows | 14:58.58 |
| paulgardiner | I don't think I have commit access, so it'll need commiting by someone else. | 14:58.59 |
| henrys | paulgardiner:let's get back to that at the ghostscript meeting in an hour, mupdf time | 14:59.30 |
| kens | Umm, I'll probably let Robin do that.... | 14:59.32 |
| paulgardiner | henrys: sure | 14:59.49 |
| henrys | mvrhel_laptop: I looked at your code best if the other mupdf'ers weigh in. | 15:00.46 |
| | particularly paulgardiner may want to make sure you guys are in sync - android and winrt | 15:01.22 |
| | Robin_Watts: I may have missed something but it looks like Christophe was left with the ball in your court. | 15:02.48 |
| mvrhel_laptop | ok. several things are currently broken on the ui viewer side but the interface to mupdf I believe is all good. for example, the text search and links on controls get back the proper stuff from mupdf through the winrt interface but I am working on how best to bind a canvas of rectangles to the xaml ui content | 15:02.57 |
| Robin_Watts | henrys: eh? | 15:02.57 |
| henrys | Robin_Watts:last email from him he said this is how I reverted the code to get things to work. | 15:03.28 |
| | I didn't see anything after. | 15:03.37 |
| Robin_Watts | Textspans? | 15:03.43 |
| henrys | textspans and how the highlight I believe | 15:03.59 |
| Robin_Watts | Most of my interaction with Christophe happens via skype. | 15:04.05 |
| henrys | Robin_Watts: okay then I'm probably missing stuff. | 15:04.26 |
| Robin_Watts | So, he's keeping his reversion, cos he wants it to work exactly as it did before, and I'm ignoring it. | 15:04.34 |
| | :) | 15:04.38 |
| henrys | I was also going to ask if the the address sanitizer bug people want to keep up they can be cc'd on the bugs - do we have permission to use their email addresses? | 15:05.32 |
| Robin_Watts | henrys: They are happy to be credited as the "Google security team". | 15:06.18 |
| henrys | the question is can marcos put their email address in the bug so we don't have to give them status on each problem. | 15:07.16 |
| Robin_Watts | pass. | 15:07.23 |
| tor8 | mvrhel: the ctx_clone stuff looks odd, robin probably knows more, but to me it looks like you're leaking the cloned context | 15:08.10 |
| Robin_Watts | I am slightly put off by the size of michaels history. | 15:08.38 |
| mvrhel_laptop | oh ok. I was not sure when I need a clone of the context and not | 15:08.40 |
| | I had thought if I had multiple threads I needed to create one | 15:09.00 |
| Robin_Watts | There looks to be lots of "do this" "fix this" "major changes" etc. | 15:09.02 |
| kens | thinlks the Google team ought to be able to supply a gmail address..... | 15:09.05 |
| mvrhel_laptop | and then destroy it when done | 15:09.06 |
| Robin_Watts | Can the history usefully be sanitised a bit? | 15:09.22 |
| mvrhel_laptop | Robin_Watts: that is because I did a major reset just about 1 week ago | 15:09.35 |
| | and things were in major shambles | 15:09.41 |
| Robin_Watts | Maybe I should take a copy of the history and shrink it all down to a single commit and look at that. | 15:09.43 |
| mvrhel_laptop | now things are coming together a little better | 15:10.04 |
| Robin_Watts | mvrhel_laptop: Right. If you have multiple threads making calls to the mupdf core at the same time you need to have cloned the context. | 15:10.28 |
| henrys | kens:I'll ask marcosw to contact them at the next meeting. Then they get real time updates and hopefully they'll leave us alone. | 15:10.34 |
| mvrhel_laptop | Robin_Watts: and then I do a fz_free_context at the end of my need for it correct? | 15:11.03 |
| | Robin_Watts: this is all in muctx.cpp | 15:11.31 |
| Robin_Watts | Right. | 15:11.32 |
| henrys | paulgardiner: so does this bring you back to signatures next week, or do you think there is a lot more to go with Raed? | 15:11.32 |
| mvrhel_laptop | Robin_Watts: ok. it seems to all be working. I have background threads rendering thumbnails of the pages while also doing full res pages in other threads | 15:12.11 |
| tor8 | mvrhel_laptop: (small aside, but you've got indentation mixed up with mixed spaces and tabs, making it hard to read in gitweb) | 15:12.12 |
| mvrhel_laptop | no collisions yet | 15:12.17 |
| paulgardiner | mvrhel_laptop: in the Android app we get away without cloning context because although there are many threads, the use of locks make it in effect only one accessing mupdf | 15:12.33 |
| mvrhel_laptop | tor8: weird. I should have all spaces | 15:12.36 |
| henrys | paulgardiner: I'm surprised how quickly you got the hang of the gs code. | 15:12.40 |
| mvrhel_laptop | tor8: I will get that cleaned up . I seem to have a lfcr issue to I see | 15:13.10 |
| paulgardiner | henrys: I didn't go very deep... only enough to be slightly horrified. In fact most of the difficulty was getting used to WinRT. | 15:13.33 |
| tor8 | mvrhel_laptop: in mupdf we use all tabs though, in case you want to fall into line :) | 15:13.33 |
| mvrhel_laptop | tor8: I have VS setup to do all spaces for gs work. switching that each time would be a pain | 15:14.01 |
| henrys | wonders how you fall into line with a proportional font but I won't go there. | 15:14.34 |
| tor8 | mvrhel_laptop: I've got separate config setups for all the different projects. | 15:14.38 |
| paulgardiner | henrys: I hope that there isn't much left to do for Raed. The only issue is that many devices had to be left out to make it build under WinRT and there may be ones he needs. | 15:14.51 |
| mvrhel_laptop | tor8: ok. I will do that same | 15:14.56 |
| tor8 | back from when gs was mandated mixed tabs + spaces | 15:14.58 |
| mvrhel_laptop | 4 spaces = tab? | 15:15.02 |
| Robin_Watts | mvrhel_laptop: No spaces at all. just tabs. | 15:15.20 |
| tor8 | mvrhel_laptop: indent = tab. no vertical alignment past the indent, so actual tab size is irrelevant. | 15:15.21 |
| mvrhel_laptop | ok | 15:15.42 |
| tor8 | broken lines like if (very long && | 15:15.58 |
| | condition) | 15:16.00 |
| | just get an extra indent level | 15:16.04 |
| henrys | Robin_Watts:anything learnt from the svg writer. Is this going to be a long drawn out thing? | 15:16.23 |
| tor8 | mvrhel_laptop: there are some git config voodoo you can do to get git to check whitespace on checkins | 15:16.50 |
| henrys | s/writer./write? | 15:17.03 |
| mvrhel_laptop | tor8: oh that would be nice | 15:17.05 |
| tor8 | mvrhel_laptop: http://ghostscript.com/~tor/stuff/git-tricks.txt | 15:18.08 |
| | that has git config core.whitespace lines for both gs and mupdf | 15:18.25 |
| | the gs one is a bit awkward because of Makefiles using tabs | 15:18.36 |
| henrys | paulgardiner:okay well hopefully you can get back to mupdf soon, perhaps chrisl should take over winrt (duck) | 15:19.02 |
| chrisl_r61 | Oh christ, hell no!!! | 15:19.15 |
| Robin_Watts | henrys: SVG writer. I have lineart and bitmaps working. | 15:19.16 |
| | clipping by path works too. | 15:19.32 |
| | text is output in the right place at the right size, but no effort to pass fonts through other than mentioning the name of the font is there. | 15:20.06 |
| tor8 | henrys: RTL bidi reordering is in, it may need some improvement after someone who actually understands arabic gives it a spin | 15:20.17 |
| henrys | tor8:yes I saw that, nice! | 15:20.33 |
| paulgardiner | henrys: some of the problems building the devices were because they used thirdparty libraries that wouldn't build, and they may be failing only because we are also building their test suites. | 15:20.46 |
| Robin_Watts | We need to do some code to cope with outputting imagemasks as PNGs. | 15:20.55 |
| tor8 | so I think that's it for the most pressing issues? does that mean I have to go back to hacking gtk+? | 15:20.58 |
| henrys | Robin_Watts:I guess a lot depends on what Raed wants - you could improve something like that for an eternity. | 15:21.23 |
| Robin_Watts | henrys: indeed. | 15:21.31 |
| | I'm trying to get tiling working now. | 15:21.38 |
| | then there is groups etc. | 15:21.48 |
| | In gs, in xpswrite, you have the advantage that fonts fallback to being drawn as lineart automatically. | 15:22.36 |
| | we don't have anything like that in mupdf. | 15:22.44 |
| henrys | tor8:well we picked gtk in part because it would work on windows - now we don't need that - we just need unix - linux - do you want to use something else? | 15:23.14 |
| Robin_Watts | but there is a "type3" like thing for fonts, so we could convert all fonts to svg fonts. | 15:23.24 |
| | henrys: EH? | 15:23.27 |
| | We DO need Windows. | 15:23.35 |
| henrys | Robin_Watts: I get that a lot | 15:23.41 |
| | we agreed we'd go platform specific on windows | 15:23.55 |
| | on all the platforms I thought | 15:24.05 |
| | michael is doing windows | 15:24.17 |
| tor8 | Robin_Watts: we just agreed to make the gtk+ one linux/unix specific and write a separate native win32 one | 15:24.18 |
| Robin_Watts | I thought we'd agreed that we'd use the gtk one on windows, and live with an installer so that the 100s of DLLs didn't matter. | 15:24.39 |
| | henrys: Michael is doing Windows RT. Not windows desktop. | 15:24.55 |
| henrys | Robin_Watts: I think you are back one agreement | 15:25.02 |
| Robin_Watts | unless he's volunteered for another batch of work. | 15:25.11 |
| mvrhel_laptop | I could leverage what I have to make a desktop version | 15:25.18 |
| | It would be much better than using gtk | 15:25.28 |
| Robin_Watts | fair enough. | 15:25.36 |
| tor8 | a windows native version is less crucial because in an emergency we can always point to sumatra | 15:25.49 |
| henrys | mvrhel_laptop: windowsrt and windows 8 we don't worry about the past - at your current pace windows 8 should be fairly well established | 15:26.03 |
| tor8 | Robin_Watts: you gave up on trying the evince backend? | 15:26.03 |
| mvrhel_laptop | going winRT to desktop should be easier than going desktop to winRT | 15:26.04 |
| Robin_Watts | tor8: I did, partly cos it wasn't looking like a quick hack, and partly cos henrys disliked the idea. | 15:26.31 |
| henrys | mvrhel_laptop: I would think winRT -> 8 would be not too scary | 15:26.38 |
| mvrhel_laptop | right | 15:26.44 |
| Robin_Watts | Hmm. There are HUGE numbers of companies still on XP. | 15:27.02 |
| henrys | tor8 has iOS and paulgardiner android and that pretty much covers us right? | 15:27.25 |
| Robin_Watts | so dropping support for XP/Vista/7 would be bad, IMHO. | 15:27.39 |
| tor8 | desperately wants to drop iOS... | 15:27.50 |
| Robin_Watts | Lots of people are flatly refusing to go to 8. | 15:27.56 |
| mvrhel_laptop | 7 should also work though with what I create | 15:27.57 |
| Robin_Watts | and XP etc? | 15:28.08 |
| tor8 | 7 would be the best, I think. XP is slowly losing traction. | 15:28.16 |
| mvrhel_laptop | XP I am not sure about. | 15:28.21 |
| tor8 | I can't imagine anyone still using Vista though | 15:28.28 |
| mvrhel_laptop | other than my father | 15:28.40 |
| Robin_Watts | tor8: right, but there are no real API changes since XP SP1. | 15:28.55 |
| | until metro. | 15:29.03 |
| tor8 | Robin_Watts: with a win32 api, yes. but there's the whole .net stuff, isn't that what mvrhel is using? | 15:29.32 |
| | managed c++ or whatever it's called these days. the code looks nothing like the c++ I'm used to seeing anyway :) | 15:29.51 |
| mvrhel_laptop | tor8: yes. I can leverage the lovely power of c# to make something work | 15:29.54 |
| | ick | 15:30.11 |
| Robin_Watts | .net works on XP, right? | 15:30.16 |
| kens | I htink that's C# tor8 | 15:30.16 |
| tor8 | kens: the file has a .cpp suffix | 15:30.38 |
| kens | OK not c# then | 15:30.45 |
| tor8 | c# works on mono! no. let's not go there :) | 15:31.26 |
| henrys | I am assuming also if anything comes of this it is 6 or more months out. | 15:32.26 |
| mvrhel_laptop | henrys: yes. thank you | 15:32.43 |
| henrys | resource wise I think 8 and rt is a good goal. | 15:33.21 |
| mvrhel_laptop | yes. that will happen relatively quickly. the legacy stuff will take a little longer | 15:33.43 |
| tor8 | I need to go afk for a bit. I will be back in 30m if there's anything else. | 15:33.54 |
| mvrhel_laptop | afk... I dont know that one | 15:34.18 |
| henrys | tor8:okay | 15:34.24 |
| Robin_Watts | Away From Keyboard | 15:34.30 |
| mvrhel_laptop | ok | 15:34.34 |
| henrys | we are 4 minutes over | 15:34.38 |
| mvrhel_laptop | Robin_Watts: there is so much going on project wise in mupdf, would you be fine writing up that content for me for the open printing summit? | 15:35.17 |
| Robin_Watts | henrys: so I plan to keep bashing on svgwrite, probably all this week, and then next week we can tell Raed where we are, and estimate how long it will be. | 15:35.25 |
| | mvrhel_laptop: sure. | 15:35.28 |
| mvrhel_laptop | I don't know if I have a handle on it all | 15:35.32 |
| | Robin_Watts: if you want, you could just write up all the mupdf stuff :) | 15:36.01 |
| Robin_Watts | mvrhel_laptop: So, something like: "What is MuPDF?" "How does MuPDF differ from Ghostscript?" "What is planned for MuPDF?" | 15:36.29 |
| mvrhel_laptop | Robin_Watts: that would be great | 15:36.38 |
| | these guys are not scared to see example code to though | 15:36.50 |
| | s/to/too | 15:36.57 |
| Robin_Watts | mvrhel_laptop: I'll scribble some text, and you can powerpoint it? | 15:37.02 |
| mvrhel_laptop | Robin_Watts: that would be great | 15:37.09 |
| | a huge huge help to me | 15:37.22 |
| henrys | yes take as much time as you need for writeup don't worry about svgwrite too much - you've got that brewing at least - good progress for now. | 15:37.39 |
| Robin_Watts | Anything to give me a break from trying to understand patterns :) | 15:37.47 |
| mvrhel_laptop | :) | 15:37.51 |
| henrys | paulgardiner: tough workout weekend and had to forgo the monday fast but sabrina continues. She looks thinner but hasn't lost weight, of course weight is tricky with water and stuff like that. | 15:40.09 |
| kens | good grief, there's mail from Raed, is he eavesdropping on irc ? | 15:42.19 |
| paulgardiner | henrys: I seem to be losing weight but not looking thinner. :-) Losing about a lb a week, and never managed that before without having every day being a miserable one! I wonder whether I'm losing muscle rather than fat, and I think I'm findng gym sessions harder | 15:42.45 |
| henrys | kens:you know if marcosw deletes the %d files each job it shouldn't be a problem. | 15:43.05 |
| | paulgardiner: 1lb/week is a lot of loss you should notice something soon. | 15:48.11 |
| kens | henrys I'm just thinking of reportgin and bmpcmp results, but I know little about the cluster | 15:50.28 |
| paulgardiner | Weight-wise, I want to lose only a bit more and then I might try fasting once a week | 15:51.04 |
| Robin_Watts | paulgardiner: Your first gs commit is in. Congratulations! | 15:51.36 |
| paulgardiner | Oh it feels so good. :-) | 15:52.27 |
| chrisl_r61 | If paulgardiner can commit to the mupdf repo, shouldn't he be able to commit to the ghostpdl one? | 15:53.18 |
| mvrhel_laptop | congrats paulgardiner | 15:53.19 |
| | brb | 15:53.24 |
| Robin_Watts | chrisl_r61: He can't commit to the mupdf repo. | 15:54.11 |
| | we review his commits and put them in. | 15:54.18 |
| | but yes, I can see no reason why he shouldn't be able to. | 15:54.29 |
| chrisl_r61 | Robin_Watts: Oh, I know he *doesn't* commit direct to the mupdf repo, didn't realise he couldn't | 15:55.45 |
| ray_laptop | morning, all | 15:56.21 |
| | kens: thanks for fixing that. | 15:56.30 |
| henrys | hi ray_laptop | 15:56.30 |
| kens | ah, np ray, I would have left it but it looked pretty obvious | 15:56.51 |
| ray_laptop | strange because I had done a regression run and it built fine | 15:56.55 |
| | I had changed the variable name from save_page_neutral to save_pageneutral and obviously missed a spot, but I don't understand how it built for my regression run | 15:58.36 |
| henrys | meeting time - how is it we break postscript viewing in a major release on linux - wow | 15:59.45 |
| kens | Only where the locale has a comma seperator I think | 16:00.17 |
| henrys | paulgardiner has made his first gs commit we'll need a 3 cheers next staff meeting for that. | 16:01.09 |
| kens | Drinks on Paul :-0) | 16:01.21 |
| mvrhel_laptop | :) | 16:01.36 |
| henrys | a few more commits and I imagine we can drink out of the flask he'll be carrying around. | 16:01.54 |
| paulgardiner | All this talk of "first" as though one terrible day I may have to make another one!! :-) | 16:02.12 |
| Robin_Watts | so, what was the plan with the metro stuff now? | 16:02.17 |
| kens | Give it to Raed I guess | 16:02.38 |
| Robin_Watts | are we punting it to Raed like this? Or is paulgardiner going to look into putting the devices back? | 16:02.40 |
| | or that may be something that chrisl should be involved in? | 16:03.02 |
| ray_laptop | paulgardiner: it's a slippery slope, alright | 16:03.16 |
| chrisl_r61 | What devices were removed, and why? | 16:03.20 |
| Robin_Watts | png devices and tif devices, IIRC. | 16:03.31 |
| kens | I'm unclear on why they didn't work, if pdfwrite works I'd have thought anything would | 16:03.34 |
| paulgardiner | I think it would be good to let Raed have a play with what we have. | 16:03.43 |
| Robin_Watts | because they made WIN32 specific calls. | 16:03.45 |
| henrys | I was hoping to ship it back to read and make a bug for broken devices for chrisl | 16:03.48 |
| | but he didn't like that. | 16:03.54 |
| ray_laptop | the libtiff and pnglib were problematic, I suspect. | 16:03.57 |
| Robin_Watts | ray_laptop: exactly. | 16:04.07 |
| paulgardiner | ray_laptop: exactly | 16:04.14 |
| kens | Well I guess we wait until the libtiff and libpng people update the libraries :-) | 16:04.17 |
| paulgardiner | :-) | 16:04.18 |
| Robin_Watts | our suspicion was that it was the test code from those libs that we don't actually need. | 16:04.28 |
| chrisl_r61 | You can certainly punt it to me, and I'll have a poke around at it | 16:04.43 |
| Robin_Watts | which may make it a configuration/build issue. hence chrisl maybe having an opinion. | 16:04.48 |
| chrisl_r61 | My opinion is: drop Windows, it's a PITA - but that probably won't fly....... | 16:05.18 |
| mvrhel_laptop | ray_laptop: should we close the bug for the customer with respect to auto color detection and do you want to let them know that it is in place? | 16:05.22 |
| henrys | chrisl_r61: don't spend too much time on it just disable the device if it is a pita | 16:05.22 |
| chrisl_r61 | henrys: I think it's worth seeing if we can pass patches upstream | 16:05.55 |
| henrys | ray_laptop:we didn't do a good job of reviewing your code, sorry. I did have a question - just one page? | 16:06.35 |
| ray_laptop | henrys: you are talking about the BGPrint=true ? | 16:06.57 |
| henrys | ray_laptop:yes | 16:07.08 |
| chrisl_r61 | FWIW, I did look at the changes, and I didn't see anything I had a problem with...... | 16:07.40 |
| ray_laptop | henrys: right. It allows parsing/clist writing of the next page while printing. | 16:07.43 |
| henrys | and my question is can we only go one page ahead? | 16:07.48 |
| ray_laptop | for a queue, I think we should go to separate rendering processes with 'save_page'. | 16:08.21 |
| | henrys: I didn't do a lot of testing, but I didn't see much advantage to bg_print mode (in fact it was slower). I suspect that clist file contention is the problem. | 16:09.26 |
| | and the parsing ALWAYS beat the rendering, so having a queue wouldn't help throughput, right ? | 16:10.27 |
| | It may be that using a memory based clist will actually help | 16:11.16 |
| henrys | ray_laptop:well I guess we can have the customer "guide" us. | 16:12.08 |
| mvrhel_laptop | a little odd that is was always slower | 16:12.12 |
| ray_laptop | I'll do some more comparisons on a wider range of files, doing ppmraw to /dev/null with disk and memory based clist | 16:12.18 |
| chrisl_r61 | ray_laptop: when I implemented something similar to this in my previous job, it didn't help, and was often slower, so we never actually used the code...... | 16:12.39 |
| ray_laptop | mvrhel_laptop: let's wait until I do more testing | 16:12.51 |
| | chrisl: now you telll me ! ;-) | 16:13.14 |
| Robin_Watts | ray_laptop: You don't want to bias the control group :) | 16:13.45 |
| henrys | ray_laptop:so you think they aren't going to balk at only 1 page. | 16:14.09 |
| chrisl_r61 | ray_laptop: by the time I realised what you were doing, you'd already done a fair amount of work. And different architectures etc not guaranteed to give the same results. The Jaws display list is *way* simpler than the clist | 16:14.22 |
| alexcher | ray_laptop: did you try to create a special test that takes long time to interpret? | 16:15.10 |
| ray_laptop | henrys: I think the customer was just trying to keep their cpus busy. parsing is always a single cpu, but they can render using multiple threads from the bg print thread | 16:16.14 |
| | alexcher: no, I didn't try that. I just wanted to use the "real world" tests | 16:16.42 |
| mvrhel_laptop | ray_laptop: makes sense | 16:17.44 |
| ray_laptop | I won't spend a lot of time doing performance tests, but I'll see if I can find a least one test were bg printing helps :-) | 16:17.58 |
| henrys | ray_laptop:they may also want to use it as a form of spooling in which case 1 page don't help. | 16:20.43 |
| | alexcher:you still haven't updated the bug in the aging report. | 16:21.56 |
| ray_laptop | chrisl: I updated the bug 693121 this AM. Whilst doing the BGPrint I found that something 'fixed itself' on Windows and I no longer need to close the clist files to open them for read (for use by the threads). | 16:22.04 |
| chrisl_r61 | ray_laptop: I saw that, that's good news :-) | 16:22.25 |
| ray_laptop | chrisl: This means that we can have 'scratch' files "delete on close". | 16:22.41 |
| henrys | paulgardiner, chrisl_r61 : are we sorted on winrt and read? | 16:22.42 |
| alexcher | henrys: I've done it. | 16:22.45 |
| chrisl_r61 | ray_laptop: yes, that's going to be much nicer! | 16:23.08 |
| henrys | marcosw:are you about? | 16:23.12 |
| paulgardiner | henrys: I had to step a way for a bit. What did we decide? | 16:23.21 |
| henrys | delete on close - yeah!!!! | 16:23.25 |
| chrisl_r61 | paulgardiner: if you can open a bug for the tiff and png devices on WinRT and assign it to me - ideally, if you could list the problem calls, too? | 16:23.50 |
| ray_laptop | my question for the group is: Do we want to have gp_open_scratch_file do that -- it changes the behaviour | 16:23.51 |
| chrisl_r61 | ray_laptop: why does that matter? | 16:24.11 |
| paulgardiner | chrisl_r61: sure | 16:24.12 |
| Robin_Watts | ray_laptop: What's the change in behaviour? Just that the files will be deleted automatically on close? | 16:24.44 |
| ray_laptop | or do we keep the current one and add a new gp_open_scratch_file | 16:24.47 |
| henrys | paulgardiner:and marcosw will probably want to communicate with the customer about the patch - so when he comes around we'll figure that out. | 16:24.47 |
| chrisl_r61 | ray_laptop: really, who, other than us, use that call?? | 16:25.11 |
| ray_laptop | Robin_Watts: exactly. If somewhere is counting on the scratch file not going away on close, it will break | 16:25.27 |
| paulgardiner | ray_laptop: I didn't realise I'd changed the behaviour. | 16:25.43 |
| Robin_Watts | Do any of the contrib devices use the temporary files? | 16:25.55 |
| ray_laptop | chrisl: I don't know that anybody else uses it | 16:25.57 |
| henrys | kens:no priority on those pcl->pdf regressions I would be very surprised to see those in practice, the misplaced origin is a strange one though. | 16:26.01 |
| kens | henrys, they both puzzle me | 16:26.19 |
| Robin_Watts | paulgardiner: You haven't. ray_laptop is proposing it as a change that is now possible/desirable because of something he did. | 16:26.24 |
| ray_laptop | Robin_Watts: it is unlikely that anybody else uses it. That's why I'm asking. Is it OK to just change the behaviour ? | 16:26.37 |
| chrisl_r61 | I would favour changing the behaviour | 16:27.00 |
| Robin_Watts | ray_laptop: grep the devices. If none of them use it, I say make the change in behaviour. | 16:27.00 |
| ray_laptop | do I hear a second ? | 16:27.14 |
| | all in favor say "Aye" | 16:27.23 |
| henrys | aye | 16:27.27 |
| chrisl_r61 | Aye | 16:27.27 |
| kens | yes | 16:27.28 |
| Robin_Watts | Whatever :) | 16:27.29 |
| ray_laptop | OK. Thanks. I'll proceed that way. | 16:27.46 |
| paulgardiner | henrys: an important pointt that Raed needs to know (whoever communicates with him) is that the WinRT app needs to have the ghostscript dll added to it as content. That may indeed have been the main problem Raed was seeing, although even if he'd have done that, he'd have created soemthing that MS wouldn't have accepted. | 16:27.53 |
| Robin_Watts | henrys: Oh, I should have said at the mupdf meeting that the mupdf internationalisation is all done; we are in many languages on google play now. | 16:29.01 |
| henrys | Robin_Watts:yes I saw that in the commit log and forgot to mention it -that's great. | 16:29.28 |
| ray_laptop | Robin_Watts: Mui Bueno | 16:29.43 |
| marcosw_ | sehr gut | 16:30.01 |
| alexcher | ray_laptop: PDF collection processor closes extracted streams and reopens them for reading. | 16:30.12 |
| henrys | paulgardiner: I think we need a bug report for winrt running on ghostscript detailing all of this so we all understand the issues. | 16:30.22 |
| ray_laptop | alexcher: and those are created with "gp_open_scratch_file" ? | 16:30.51 |
| Robin_Watts | henrys: gs/doc/WinRT.htm ? | 16:30.51 |
| alexcher | ray_laptop: I need to check this. | 16:31.25 |
| paulgardiner | I have to go, but I'll check logs tomorrow | 16:31.53 |
| henrys | I hate to create bugs after they're fixed but I know this is going to go completely undocumented. WinRT.htm is fine too. | 16:32.03 |
| Robin_Watts | paulgardiner: Have fun. | 16:32.04 |
| henrys | bye paulgardiner | 16:32.14 |
| ray_laptop | alexcher: if it uses the PS .tempfile operator (as it probably does), then, yes it uses gp_open_scratch_file | 16:32.51 |
| | :-( | 16:32.55 |
| henrys | marcosw:so we wanted to ask you about testing %d in pdfwrite. | 16:33.12 |
| alexcher | ray_laptop: yex, it does. | 16:33.15 |
| | ray_laptop: yes, it does. | 16:33.22 |
| ray_laptop | psi/zfile.c line 708 | 16:33.26 |
| henrys | marcosw_ ^^^ | 16:34.00 |
| marcosw_ | henrys: you mean writing to multiple pdf files? | 16:34.22 |
| | one per page | 16:34.26 |
| ray_laptop | OK. So I'll create an gp_open_scratch_file_auto_delete (and 64 variant) and change pdfwrite and clist to use that | 16:34.34 |
| henrys | correct we have good reason to believe that will break things marcosw_ | 16:34.50 |
| marcosw_ | would that be instead of or in addition to the pdfwrite testing we are doing now? | 16:35.11 |
| ray_laptop | auto_delete or auto_rm ? anybody have a better (or shorter) name idea ? | 16:35.13 |
| marcosw_ | or just a one time test? | 16:35.17 |
| henrys | marcosw_:I think we can just do it once. | 16:35.22 |
| | kens? | 16:35.29 |
| kens | I'd say once is enough | 16:35.36 |
| marcosw_ | henrys and kens: I'll make it so. | 16:35.56 |
| henrys | sorry we've gone 5 over meeting time. | 16:35.56 |
| kens | not a problem | 16:36.05 |
| alexcher | ray_laptop: perhaps, PDF collection handler doesn't need to close the files. | 16:36.08 |
| henrys | marcosw_:great | 16:36.11 |
| marcosw_ | did anyone take a look at the coverage/test file analysis: http://marcos.mine.nu:8080/coverage/gs/ | 16:36.53 |
| ray_laptop | alexcher: please check into it and let me know. But we'd have to change the documenation on .tempfile | 16:37.05 |
| marcosw_ | is it useful enough that I should automate updating it? | 16:37.10 |
| kens | marcoswe I looked at it but didn't really understand it | 16:37.34 |
| ray_laptop | alexcher: If we can work with auto_delete then it will allow us to get rid of all the stuff we do to keep a 'tempfiles' list | 16:37.55 |
| marcosw_ | kens: it shows which source lines are exercised by which test files/parameters. | 16:38.59 |
| Robin_Watts | marcosw: I looked at it, it looked neat, but I haven't 'used' it. | 16:39.00 |
| kens | marcosw it didn't seem to work too well for me on FIrefox when checking pdfwrite | 16:39.29 |
| Robin_Watts | I'd probably use it more with mupdf at the moment :) | 16:39.45 |
| henrys | I did look at the coverage I'm sort of waiting for pcl. | 16:40.51 |
| | marcosw_ ^^^ | 16:41.00 |
| marcosw_ | kens: I didn't test with firefox (nor explorer), so it's possible that it's broken with firefox. It's pretty simple css but I'll test with firefox. | 16:41.20 |
| | henrys: yeah, I figured you say that :-) I'll run the pcl code. | 16:41.43 |
| kens | My firefox won't run lots of stuff, because I've disabled it :-) | 16:41.43 |
| henrys | I did look at gdevp14.c and see large areas of unused code - alarming. | 16:42.15 |
| kens | henrys untested rather htan unused | 16:42.29 |
| | Lots of pdfwrite falls into that category too | 16:42.48 |
| henrys | kens:right | 16:42.59 |
| kens | There's huge swathes of code in pdfwite that only get exercised when certain options are specified | 16:43.25 |
| | Trying to test them all, even once would be mind-boggling | 16:43.52 |
| ray_laptop | henrys: there are many transparency blend modes that don't get used, but I think the PDF ref manual has examples that use those modes. | 16:45.13 |
| henrys | I don't know if we can get all the error paths but we should be able to hit all the functionality ... | 16:45.15 |
| kens | henrys, not in pdfwrtite, not really | 16:45.34 |
| henrys | kens:hard for me to imagine non error/fallback stuff we can't reach what exactly are you thinking of? | 16:47.55 |
| | kens:assuming we are willing to handcraft a test. | 16:48.31 |
| kens | color conversion strategy, downsample type, font embedding | 16:48.53 |
| | etc. | 16:48.58 |
| | The list of possible options in pdfwrite is quite large | 16:49.28 |
| Robin_Watts | We have a test type for mupdf in the cluster called "mujstest". This involves running mujstest on a set of .mjs files. | 16:49.29 |
| | Each .mjs file specifies a .pdf file to open, and then prods at it in various ways to set fields etc. | 16:49.55 |
| | We could write something much simpler for ghostscript. | 16:50.10 |
| kens | The list of options, and combinations of options, is rally quite large | 16:50.34 |
| Robin_Watts | Say we could have a set of .gss files, each of which would contain the name of a pdf file, and the set of options to use, and maybe the tests to do on the results. | 16:50.49 |
| | Then for every feature, we just commit a new .gss file to the svn test repo in a given directory, and when the cluster runs, it would run gs with those options and look at the results. | 16:51.42 |
| | That way kens can have control over the tests without needing to get dirty with changing the cluster code. | 16:52.11 |
| kens | Its the sheer number of runs that would need to be done that copncerns me | 16:52.33 |
| | There's also PDF/A, PDF/X, and subsets of those | 16:53.01 |
| Robin_Watts | kens: I'm not saying we should run every possible file with every possible combination. | 16:53.13 |
| kens | Robin_Watts : just enumnerating the possible set of controls boggles my tiny brain | 16:53.37 |
| Robin_Watts | Start off with a simple smoke test; one file for each option. | 16:53.50 |
| | Then whenever you have a problem with a particular combination, add a new .gss file. | 16:54.03 |
| henrys | actually kens can just write a postscript example with any options he wants. | 16:54.40 |
| kens | Indeed, given a few years spare time | 16:54.55 |
| henrys | why gas? | 16:54.55 |
| | s/gas/gss | 16:55.04 |
| Robin_Watts | henrys: Not if he wants to test pcl -> pdf say. | 16:55.12 |
| | or xps to pdf. | 16:55.21 |
| kens | Most controls don't work at all with PCL | 16:55.27 |
| | or XPS | 16:55.32 |
| Robin_Watts | a .gss file might be something like: | 16:55.34 |
| henrys | kens:well let's all have a look at the coverage data - and if we see something that is not tested and is something a customer might trip over let's try to make a test. Does that seem reasonable? | 16:56.12 |
| kens | And to be honest, we don't need to test pdfwrite coverage by using PCL | 16:56.17 |
| | henrys that's a farily mammoth task for me | 16:56.47 |
| Robin_Watts | OPTIONS: -sDEVICE=pdfwrite -sSomeFunkyOption=Pink | 16:57.05 |
| | FILE: fred.pdf | 16:57.07 |
| | FILE: zippy.pdf | 16:57.09 |
| | FILE: george.pdf | 16:57.11 |
| | FILE: bungle.pdf | 16:57.13 |
| | OR we can be simpler and restrict ourselves to one input file per .gss | 16:57.36 |
| kens | Without hand-crafting tests one input file owuld not be sufficient | 16:57.57 |
| Robin_Watts | kens: Well, you can commit lots of .gss files, each with 1 file. | 16:58.36 |
| | but the point is to have an extensible system that kens/others can use to add their own tests for specific options without having to bash on the cluster. | 16:59.12 |
| kens | Robin_Watts : I can do it, I cna hand-craft PS files to fo it fight now, but it will take me a long time to write enough files to exercise those portions of the code that are not currently tested | 16:59.44 |
| | Robin_Watts : as henrys says I cna do it all in PostScirp tright now | 17:00.04 |
| henrys | we aren't close to coverage without options. I'm doing that first in pcl. | 17:00.06 |
| kens | Well I have to go cook dinner, goodnight all | 17:00.41 |
| henrys | but I am pretty close in pcl to line coverage. | 17:00.42 |
| Robin_Watts | The same gss idea works for options in pcl too. | 17:00.43 |
| kens | Robin_Watts : no,because almost all options simply don't work in PCL or XPS, so they can't be tested | 17:01.07 |
| | There's a bug for that too | 17:01.19 |
| henrys | Robin_Watts:I'm fine if you add the option stuff - if you don't I'll probably expand PJL to handle testing the other languages, it is fairly easy to set device and user parameters with that. | 17:05.14 |
| | and it is an extensible language | 17:05.25 |
| Robin_Watts | henrys: Fair enough. If you're prepared to hand craft test files, then fine. | 17:09.49 |
| | Sounds like a larger amount of work to me, but... | 17:10.34 |
| ray_laptop | question for whoever's left around. Does anyone think that BGPrint for page buffer mode would be useful ? I didn't think so because the parsing and rendering to the page buffer would all be in a single thread and the only thing the bg_print thread would do is format and output. | 17:15.30 |
| | but for some fomats like jpeg and png, the compression is a fair amount of the work. Anybody care to comment ? | 17:16.07 |
| henrys | Robin_Watts:I don't know that it will be much work. We are not trying to execute all paths, just make sure each line of code is covered, I don't know why kens thinks this would be so much work. If we were covering all paths there would be combinatorial explosion, that's not the goal. | 17:19.48 |
| Robin_Watts | ray_laptop: I'd not considered BGPrint as being something that would be practical for page mode things. | 17:31.37 |
| ray_laptop | Robin_Watts: thanks. I agree. | 17:39.46 |
| Robin_Watts | I mean, I'd not considered it. | 17:40.17 |
| | It might be useful for things like jpeg and png. On a dual core machine, for example, could that mean faster operation? One core interprets/renders, another handles the compression? | 17:41.13 |
| | mvrhel_laptop et al: MuPDF openprinting blurb sent. Let me know if anyone sees anything I missed (or if I need to explain any part of the points) | 18:08.08 |
| mvrhel_laptop | Robin_Watts: awesome thanks! | 18:08.22 |
| | Robin_Watts: it looks great. thanks. I may have some questions for you later in the week | 18:16.53 |
| Robin_Watts | fab. | 18:17.48 |
| ray_laptop | 108 of 159 multipage PDF's are faster with BGPrint=true ! That's from one run through. YMMV. | 18:21.25 |
| | still, it's better than I expected | 18:21.39 |
| | I may do another couple of runs and take the minimum from each run with and without. | 18:22.43 |
| mvrhel_laptop | ray_laptop: great! | 18:22.57 |
| ray_laptop | I tested only in -sBandListStorage=memory ppmraw -o /dev/null but that takes the disk out of the process | 18:24.20 |
| | of the 61 tests that ran for more than one second, we were only more than 1% slower on 7 of them | 18:30.18 |
| Dadman | i have a question about the api to mupdf, is this the right place to ask ? | 18:36.17 |
| sebras | Dadman: it is, what are you curious about? | 18:42.38 |
| Robin_Watts | mvrhel_laptop: sebras points out that we should have contact info and mention irc on the last slide of the mupdf stuff. | 18:53.53 |
| mvrhel_laptop | Robin_Watts: definitely. | 18:54.31 |
| sebras | mvrhel_laptop: Robin_Watts: maybe I ought to just have replied to the mail, but irc always seem quicker. :) | 18:58.52 |
| Robin_Watts | sebras: Why is djvu not on the agenda? Patents? | 19:26.55 |
| tor8 | Robin_Watts: patents. | 19:33.50 |
| | the Z' arithmetic encoder and I believe one other in the IW44 wavelet thingy | 19:34.10 |
| Robin_Watts | not freely available for decoders then? | 19:35.48 |
| | http://djvu.sourceforge.net/licensing.html | 19:37.25 |
| | So... OK for GPL, not for commercial. | 19:37.36 |
| | It sounds like we should maybe contact LizardTech and ask. | 19:37.57 |
| | It's possible that they would be happy to see us support djcu. | 19:39.05 |
| tor8 | afaiu it's freely available if you fork your code from the reference software release | 19:42.17 |
| | but then you're limited to gpl | 19:42.28 |
| | Robin_Watts: I wrote a partial djvu decoder in my spare time. it does the BZZ (regular chunks) and JB2 bits, but not the wavelets | 19:44.02 |
| | the reference lib is all really icky c++ | 19:44.32 |
| | lots of "framework" and "design" stamped all over it | 19:44.51 |
| Robin_Watts | tor8: Should I drop LizardTech a line enquiring? The worst thing they can do is say "no, you can't have rights", in which case we're no worse off than now. | 19:49.44 |
| | henrys: ^ | 19:49.50 |
| tor8 | can't hurt. best make sure they're still the current owners though, I know the patents changed hands a few times | 19:50.17 |
| henrys | they've already asked to do a cross license deal with miles and we said no. | 19:50.33 |
| tor8 | right then | 19:50.42 |
| | henrys: what did they want of ours? | 19:51.07 |
| henrys | ghostscript | 19:51.26 |
| | why does sebras or anyone think djvu would be interesting? I never hear anything about it, but maybe I'm not listening in the right places. | 19:54.22 |
| sebras | henrys: I usually see djvu mentioned in the context of multi-format document readers. | 19:55.18 |
| | we've had people ask about it here too, I think. | 19:55.37 |
| | henrys: sumatrapdf does djvu, as does vudroid (the pdf part of which is based on mupdf). | 19:57.50 |
| | but I don't know openprinting, so maybe this is not interesting for that crowd. | 20:02.57 |
| henrys | I don't mind asking miles will not like the business of making GPL better than commercial though. | 20:06.02 |
| Robin_Watts | henrys: Right. I'll drop them a line and ask. | 20:06.19 |
| | It's possible that they will be happy to let us have rights to decode files. | 20:06.35 |
| | but I'll explain that doing GPL without doing the commercial version is a non-starter for us. | 20:06.52 |
| henrys | is sumatra pdf just supported by the adds I see on their page? | 20:09.08 |
| ray_laptop | For BGPrint=true, taking the minimum of two runs (so far) there are 97/159 that are same or faster (only 53/159 that are at least 1% faster) and 124/159 are no worse than 1% slower. Of the 61 files that ran for more than a second, only 6 were more than 1% slower. | 20:09.12 |
| | re djvu, what's the issue with the arithmetic and wavelet. Our commercial customers get Luratech JPEG2000 and JBIG2 which uses both. Can that help us ? | 20:14.34 |
| Robin_Watts | ray_laptop: Different arithmetic encoders. | 20:14.50 |
| ray_laptop | like the world needs more than one arithmetic codecs (probably they are equivalent advantages except for working around patents) :-( | 20:15.48 |
| | good thing nobody copyrighted arabic numerals -- we'd still be using Roman numerals | 20:17.26 |
| | I recall Peter having a "brain dead" LZW encoder that could be decoded by LZW decoders, but didn't violate the patents. | 20:20.02 |
| | it didn't compress very well | 20:21.05 |
| Dadman | I'd like to send a byte stream for a pdf file to mupdf, but the api seems to require a filename. Is there an alternative ? | 21:04.25 |
| sebras | Dadman: mupdf's core library provides fz_open_memory(), which can parse a complete pdf-file stored in a RAM buffer. | 21:22.16 |
| | though this function is not currently exposed in the android wrapper. | 21:22.31 |
| Dadman | if by the android wrapper you mean via a jni call to java, i can give that one a try. however are there any test suites i can run to ensure i don't cause any unexpected side effects ? | 21:38.14 |
| sebras | Dadman: yes, exactly. I believe that there is an idea to have the jni wrapper expose more of the core mupdf interface eventually. no, there are no testsuites for this that I know of, sorry. | 22:11.04 |
| Dadman | ok, i will give it a go. thanks for the feedback on the right api. | 22:39.08 |
| Robin_Watts | There is an interface for sending a byte buffer in already. | 23:26.25 |
| | Forward 1 day (to 2013/05/08)>>> | |
IRC Logs