| <<<Back 1 day (to 2013/03/19) | 2013/03/20 |
vtorri | hey | 07:35.42 |
| is it normal that the link http://ghostscript.com/~giles/jbig2/jbig2dec/jbig2dec-0.11.tar.gz does not work ? | 07:35.54 |
| i need jbig2dec for mupdf | 07:36.10 |
chrisl | jbig2dec is included in the mupdf release archive | 07:36.37 |
Robin_Watts | Morning tor8. | 10:44.55 |
| Some reviews for you. | 10:44.59 |
| 6 reviews there. Oldest 3 should be good to go. | 10:45.55 |
| 4 is good to go if you think it's useful. | 10:46.34 |
tor8 | Robin_Watts: set_font_bbox is almost a duplicate of fz_set_font_bbox | 10:47.22 |
| Robin_Watts: and good morning :) | 10:47.31 |
| I also have a couple of patches on tor/master, but hold on the utf-8 password one for now | 10:48.07 |
| there's a patch I have on another machine I need to rebase into it | 10:48.18 |
Robin_Watts | ok. | 10:48.31 |
| set_font_bbox could be implemented as an if, plus 2 calls to fz_set_font_bbox | 10:49.58 |
| not sure I see that as being hugely better though. | 10:50.10 |
| Of are you suggesting that fz_set_font_bbox should get the if logic too ? | 10:50.31 |
| s/Of/Or/ | 10:50.37 |
tor8 | I thinking the latter | 10:52.30 |
Robin_Watts | Updated patch there for your consideration. | 11:03.44 |
| so pkg-config on macos doesn't know about the X libs? | 11:04.44 |
| tor8: Your patches look good to me. I'll pull them in and push them out. | 11:07.41 |
tor8 | Robin_Watts: pkg-config doesn't exist on macosx | 11:11.20 |
| unless you've installed it yourself | 11:11.34 |
Robin_Watts | good answer. | 11:12.02 |
tor8 | also, about having skip pointers in the display list. it shouldn't be too expensive to iterate (and update the progress counter) and skip processing the list until the clipnode->skip node is reached | 11:15.12 |
Robin_Watts | The current patch skips. | 11:15.58 |
tor8 | instead of just more efficiently skipping | 11:16.04 |
Robin_Watts | but I forgot to update the progress counter. | 11:16.10 |
| tor8: So are you pro or anti skip pointers? :) | 11:16.34 |
tor8 | yes, skipping as you did in the patch is fine. but in another patch let's move to skip pointers (but still iterate until we can solve the progress counter) | 11:17.05 |
Robin_Watts | tor8: Updated version of the patch that keeps progress updated too. | 11:29.56 |
tor8 | kens: I've replied to the stackoverflow question again. it looks odd, but my hunch is that the "make generate" step didn't run fine for him. | 11:42.43 |
| Robin_Watts: we have gettimeofday (and a win32 implementation using win32 calls under the hood) to do accurate time keeping | 11:44.40 |
| clock() returns cpu time used, not wall clock time, IIRC | 11:45.29 |
Robin_Watts | tor8: indeed. | 11:46.52 |
| I have some other code on peeves or on my local linux that uses gettimeofday I think. | 11:53.03 |
| Are you happy with the first 3? | 11:53.14 |
Robin_Watts | runs | 11:54.46 |
tor8 | Robin_Watts: yes. first three are good to go. | 11:57.30 |
| is the glyph scissor at render time one finished? | 11:58.43 |
Robin_Watts | yes, but malcs tests didn't show any massive improvements. | 11:59.36 |
tor8 | right. and it does slow down all text rendering doesnt' it? | 12:00.05 |
sojic | Hi folks... Anybody to help me with pdf to jpg and cropbox/trimbox? | 12:37.05 |
Robin_Watts | tor8: yes, in theory it slows it down a bit (extra checks) | 13:15.52 |
tor8 | Robin_Watts: there's the extra vertex/matrix mults per glyph | 13:16.18 |
Robin_Watts | I could make it a build switch I guess. | 13:16.23 |
| yes. | 13:16.25 |
tor8 | I'm not opposed to either having or not having it, but please no #ifdef crap | 13:18.00 |
mvrhel_laptop | henrys: I can't make the 8am meeting today but I will be here for the 9am meeting. have to run kids to school | 14:42.42 |
henrys | mvrhel_laptop: okay | 14:42.59 |
| chrisl:warning about no fco files found when doing the pcl build with regular configuration | 14:44.27 |
| ? | 14:44.36 |
chrisl | <shrug> | 14:44.46 |
henrys | ROMFS_ARGS must be getting set incorrectly. | 14:45.40 |
chrisl | I'll check it when I have time | 14:45.55 |
henrys | okay | 14:46.16 |
chrisl | henrys: I don't get any such warning | 14:56.38 |
henrys | chrisl: let me clean and build | 14:57.30 |
| chrisl: my bad looks good now | 15:00.05 |
chrisl | henrys: phew, I was worried we were seeing different results! | 15:00.34 |
henrys | sojic:just ask your question lots of ps and pdf experts here. | 15:00.39 |
| tor8 RobinWatts: meeting? | 15:01.28 |
| paulgardiner also of course | 15:01.41 |
paulgardiner | I'm here | 15:02.04 |
kens | Oh an hour early because we still on daylight sabings | 15:02.11 |
sojic | Never mind... figured by myself... but... Is it possible to convert pdf to jpg but only artbox, without BleedBox and CropBox? I've done it by: 1. "pdfinfo -box" to find "margins", then convert pdf with: "gs -sDEVICE=pdfwrite -o x.pdf -c "[/CropBox [14.17 14.17 637.80 822.05] /PAGES pdfmark" -f 109.pdf" then convert to jpg | 15:03.36 |
| Is it possible directly? | 15:03.48 |
kens | -dUseArtBox probably | 15:04.01 |
| -dUseCropBox certainly works | 15:04.10 |
henrys | paulgardiner: how was key west? | 15:04.39 |
paulgardiner | Great. Drive down from Miami was far prettier than I'd been led to believe. | 15:05.40 |
henrys | paulgardiner: that is a US epic road trip | 15:06.20 |
sojic | dUseCropBox doesn't work for me... because pdfinfo say: cropbox 0 0 600 800, but artbox: 33 33 577 777 | 15:07.07 |
henrys | paulgardiner: anyway we'll just catch up with folks as they appear. I was a bit confused if you were doing digital signatures or Robin_Watts was taking that on. | 15:07.56 |
paulgardiner | Food was good... ate far too much. Moved from 5/2 to 14/-7 (assuming that's how one should denote eating 14 days food in 7 days | 15:08.00 |
henrys | paulgardiner: I think it is very difficult to be on a diet all the time. | 15:08.58 |
| paulgardiner: today is day 2 this week with sabrina and I. | 15:10.01 |
paulgardiner | henrys: I'm not sure what we decided either. I'd be happy do do it. I guess it's md5 and rsa, that sort of thing | 15:10.02 |
kens | sojic did you try -dUseArtBox ? I don't know if that works, I don't handle the PDF interpreter normally | 15:10.25 |
paulgardiner | henrys: you are doing two days ina row?! I guess that gets it out the way. | 15:10.31 |
| Hang on, it's wednesday | 15:10.38 |
henrys | kens:when do daylight saving start for you? | 15:10.39 |
paulgardiner | I lost a day | 15:10.41 |
henrys | paulgardiner: no monday and wednesday | 15:10.49 |
kens | henrys I believe the end of the month | 15:10.49 |
sojic | kens, I've tried with -dUseTrimBox, but Crop Marks stay | 15:11.23 |
paulgardiner | henrys: hope you sleep better tonight. | 15:11.27 |
henrys | kens:the only thing stupider than changing the clocks is not changing them together ;-) | 15:11.44 |
kens | henrys I agree :-) | 15:12.02 |
| sojic did you try -dUseArtBox ? I believe from a quick search that this should work | 15:13.19 |
sojic | Let me try | 15:13.34 |
Robin_Watts | Apparently I'm supposed to be on a con-call now :( | 15:15.14 |
paulgardiner | Where does signing fit in priority-wise with the annotations work (although I guess it's part of it, in a way)? I'm working on Ink annotations at the moment. Just have them creatable on the java side and working on saving them to the doc. | 15:15.43 |
henrys | paulgardiner: I'm thinking it is equal with the annotations. | 15:16.58 |
| Robin_Watts: NP | 15:17.26 |
sojic | kens (and others): http://butterfly.venikom.com/pdf/sourcePdf/crop_marks_4/104.pdf converted with: "gs -dNOPAUSE -sDEVICE=jpeg -dFirstPage=1 -dLastPage=1 -sOutputFile=x.jpg -dJPEGQ=100 -r300x300 -dUseArtBox -q 104.pdf quit" result: http://butterfly.venikom.com/pdf/sourcePdf/crop_marks_4/x.jpg | 15:19.30 |
kens | Well I'd have to see the original file (not a rendering, the PDF) but it sounds like you have a solution already. Simpler would be to create the PDF file correctly with the right CropBox ;'-) | 15:20.41 |
paulgardiner | henrys: maybe I should also look at cloud-based printing in the android app. Might just come down to sending the pdf somewhere | 15:20.54 |
henrys | paulgardiner: I do think that would be a good thing to look at if you have time. | 15:21.33 |
paulgardiner | ok np | 15:21.55 |
henrys | paulgardiner: could you do a short writeup on what you find in next week's status report so the staff sees it? | 15:22.23 |
paulgardiner | On the printing? Sure. | 15:22.57 |
| I think Adobe Reader on Android is trying to confuse me by offerring to add a signature to a document, but it looks to be just an Ink Annotation, with a different color and thickness. | 15:24.17 |
| I'll take a look at the saved result, see if it has also digitally signed the document. | 15:25.27 |
henrys | paulgardiner: wow that seems bad if folks really believe it is a signature | 15:25.37 |
paulgardiner | Yes, weird. | 15:26.36 |
henrys | paulgardiner: how is that not a security violation | 15:26.40 |
paulgardiner | It may well be signing aswell. I'll have a look. | 15:27.31 |
henrys | Robin_Watts: miles told me wednesday but didn't give me a time. | 15:30.29 |
Robin_Watts | Con-call over. | 15:42.06 |
| I had no idea I was expected on a con-call til Miles rang me to ask why I was late :( | 15:42.22 |
henrys | Robin_Watts: maybe I was supposed to tell you but like I said he just gave me a day so I assumed he was handling the details. | 15:48.00 |
| brb | 15:49.02 |
Robin_Watts | ok, back. | 15:53.52 |
henrys | how'd it go? | 15:54.37 |
| Robin_Watts: ^^^ | 15:54.52 |
Robin_Watts | (sorry, was reading logs) | 15:55.17 |
| It went fine. | 15:55.21 |
| There is a limit to what I can say on here. I'll write an email about it and send it round. | 15:55.39 |
| Digital Signatures - not sure if that fell to Paul or to me. | 15:56.16 |
| It's a file level thing, rather than an object level thing (i.e. it needs hackery at the pdf file/xref reading level rather than within objects) | 15:56.54 |
| I'm happy to look at it, or happy to let paul look at it. I've not invested any time into it so far other than investigating the original bug. | 15:57.34 |
henrys | Robin_Watts: ti would seem an opportunity for paul to get beyond the ui in mupdf which is good. | 15:58.08 |
paulgardiner | Would we use openssl? Would mean adding another third-party library/ | 15:58.09 |
Robin_Watts | paulgardiner: We haven't had to use openssl yet. | 15:58.44 |
| and we already support various encyption things. | 15:59.00 |
paulgardiner | rsa? | 15:59.12 |
mvrhel_laptop | ok I am here | 15:59.12 |
henrys | I would think you already have the encryption stuff | 15:59.16 |
mvrhel_laptop | for regular meeting | 15:59.25 |
henrys | Robin_Watts: so assigned to paulgardiner if no objections | 15:59.49 |
Robin_Watts | henrys: paulgardiner is far beyond the UI already. But no, no objections. | 16:00.00 |
paulgardiner | Fine by me | 16:00.01 |
henrys | okay next meeting | 16:00.28 |
| I did have more for mupdf but we can talk some other time, I don't think tor8 is about anyway. | 16:01.01 |
paulgardiner | I see md5 in the source, but not rsa - I guess I should read the specs first: maybe they don't use rsa. | 16:01.04 |
alexcher | marcosw: I've installed Imagemagick on alex_i7b. | 16:02.21 |
henrys | alexcher:is it okay if I broadcast your meeting additions to tech directly? | 16:02.23 |
alexcher | Yes. of course. | 16:02.51 |
henrys | or you can do it and we'll read them and comment here | 16:02.57 |
| alexcher had submissions for the agenda which I didn't get pulled into the meeting. | 16:03.29 |
marcosw1 | alexcher: thanks. Now if Robin_Watts fixes the indeterminism in tiffscaled output I can add that device to cluster testing (need it to convert tiff files for bmpcmp). | 16:03.46 |
alexcher | henrys: Forwarded. | 16:05.00 |
henrys | marcosw1:you wanted to discuss kens closing of customer 1 issues with embedded fonts. | 16:05.55 |
| marcosw1:I think the latter can be made a duplicate as kens said | 16:06.33 |
marcosw1 | henrys: and <http://bugs.ghostscript.com/show_bug.cgi?id=693701>? | 16:07.45 |
henrys | yes 700 and 701 we are talking about. | 16:08.26 |
| 700 can be made a duplicat. | 16:09.08 |
| . | 16:09.09 |
| duplicate | 16:09.15 |
Robin_Watts | marcosw1: That's my next piece of work. | 16:09.21 |
henrys | for 701 I agree with kens - an option to shoot us in the foot. | 16:10.26 |
kens | :-) | 16:10.35 |
henrys | but others may want to weigh in. | 16:10.42 |
marcosw1 | henrys: should we disable the /NeverEmbed option then? The same argument can be made for it. | 16:11.02 |
kens | marcosw1 but Acrobat permits that. And it has uses *in a tightly controlled workflow* | 16:11.21 |
| a wildcard does not in my opinion | 16:11.29 |
marcosw1 | kens: Acrobat also has a setting to /NeverEmbed all fonts. | 16:11.54 |
kens | I haven't seen that, where is it ? | 16:12.07 |
| I don't see any likely control in DIstiller | 16:12.50 |
henrys | chrisl:with you changes to set the font scaler during configure can we now get rid of all the extra makefile targets "udebug etc." | 16:13.53 |
chrisl | henrys: not if we want people to have the old integration as a fallback for a while | 16:14.27 |
marcosw1 | You set distiller to write a "small file" (that's what the customer told me, I didn't try it, but since he attached a file with no fonts embedded I presume it does work that way). | 16:14.37 |
kens | marcosw1 I see no such control | 16:15.00 |
| Tell me where it is ? | 16:15.06 |
ray_laptop | kens: I agree with you w.r.t. wildcards but supporting /NeverEmbed [ /All ] (similar to /None and /All special names in colors) | 16:15.34 |
henrys | chrisl:I wonder if worrying about that is more significant than the confusion. | 16:16.09 |
| but either way. | 16:16.13 |
ray_laptop | but I also agree that this is a BAD idea since the PDF is no longer "Portable" | 16:16.32 |
chrisl | henrys: it was your preference to have it that way! | 16:16.36 |
henrys | chrisl:what does that have to do with anything ;-) | 16:17.37 |
marcosw1 | kens: I need to look. | 16:17.43 |
chrisl | henrys: just so long as I don't get the blame...... | 16:17.58 |
kens | If there is such a control in Distiller we will wnat to do the same if we choose to do so (butits a really stupid idea) | 16:18.15 |
chrisl | Given that we've both just been berating someone on bugzilla for not embedding fonts....... | 16:18.58 |
marcosw1 | kens: before I spend time looking for the setting, will finding it convince you to add this feature? If not there really isn't any point for me to look. | 16:19.01 |
kens | won't convince me, will add weigt to the argument in favour | 16:19.21 |
henrys | chrisl:no I like the configure work and I think that should be the only source of configuration. | 16:19.25 |
chrisl | henrys: but we have two build options *with* the alternate font scaler | 16:20.13 |
ray_laptop | PDF's are already pretty non portable ever since we started respecting the TTF flag restricting embedding | 16:20.32 |
henrys | chrisl:I guess I'm confused one sets the font scaler with configure so we don't need targets like "udebug" in the makefile. | 16:21.21 |
ray_laptop | we could just tell cust #1 to use a font editor to set the flag in their fonts, and when they don't want any fonts embedded use the "protected" set of fonts, rght ? | 16:21.40 |
chrisl | henrys: but then you have the choice between working through FAPI, and the old PCL/PXL integration | 16:22.21 |
henrys | something I wanted to bounce off everyone: we do get good google juice from ghostscript.com, what do you think about recommending or not of outside products: pdf995 - not recommended no contribution to open source, maybe one of our customers and pdfcreator (good GPL citizen) we do recommend. | 16:23.55 |
Robin_Watts | henrys: Saying "avoid product XXX as it's bad" will get us sued (or is bad Karma at least) | 16:25.08 |
henrys | chrisl:okay I thought that was dynamic and had nothing to do with the Makefile targets | 16:25.24 |
Robin_Watts | Saying "Why not try product YYY" is better, but then we might be seen to be preferring one customer over another. | 16:25.42 |
ray_laptop | Robin_Watts: we can't be sued for issuing a statement of opinion like "we do not recommend" AFAIK | 16:25.49 |
chrisl | henrys: no, it's a build time decision | 16:25.52 |
henrys | Robin_Watts:I'm saying we don't recommend it because there no open source contribution which is true | 16:25.55 |
| chrisl:oh okay | 16:26.13 |
| you had it dynamic in gs | 16:26.24 |
Robin_Watts | ray_laptop: Right, but since when has that ever stopped lawyers :) | 16:26.26 |
chrisl | henrys: no, never was dynamic in gs | 16:26.42 |
| henrys: gs never had a non-FAPI way to use the "other" font scaler | 16:27.17 |
henrys | legally you get in trouble when there is libel or defamation | 16:27.41 |
| I don't think my statement would come close to that. | 16:27.59 |
| anyway maybe something to think about for a bit. | 16:28.20 |
Robin_Watts | henrys: A concrete suggestion of words would be easier to think about. | 16:28.44 |
henrys | chrisl: disableFAPI | 16:28.54 |
| Robin_Watts: sorry I'll cook up something and pass it around. | 16:29.11 |
chrisl | henrys: that sends you back to the AFS code | 16:29.35 |
Robin_Watts | marcosw: The addition of the aws things on the dashboard makes the machine list huge. Should I split that into 2 columns? or are they going to disappear soon? | 16:30.20 |
marcosw1 | kens: if you set the "Default Settings" to "Smallest File Size" it generates a PDF file with no fonts embedded (see <http://www.ghostscript.com/~marcos/screenshot.png>). | 16:30.36 |
ray_laptop | Robin_Watts: I recommend 2 columns | 16:30.44 |
kens | marcosw1 and what distiller setting controls that ? | 16:30.51 |
marcosw1 | kens: it's the "Default Settings". You set that to "Smallest File Size". | 16:31.28 |
kens | That's a collection of settings marcosw1 what parameter shoudl I set to achieve this ? | 16:31.50 |
ray_laptop | kens: I don't think the Acrobat UI shows you the distllerparams stuff | 16:31.55 |
marcosw1 | Robin_Watts: can you have cluster machines that have been down for >2 hours disappear from the dashboard? | 16:32.07 |
kens | It shows many ray_laptop | 16:32.08 |
| I can't have a 'smallest file setting' so I need the distillerparam and I can't find one. And I'm still unconvinced its a good idea. | 16:32.37 |
Robin_Watts | marcosw1: Urm... possibly. but is that ideal? | 16:32.38 |
| I could have aws ones that have been down for more than 2 hours disappear, but often it's nice to see that (say) miles is down. | 16:33.14 |
chrisl | Robin_Watts: I was thinking about sticking the aws nodes at the bottom of the page | 16:33.19 |
henrys | chrisl:yes now I have it sorted there are two issues - FAPI and which font scaler for PCL | 16:33.55 |
| chrisl:which are mostly separate | 16:34.11 |
marcosw1 | Robin_Watts: sorry, I meant nodes that have the name aws*. | 16:34.13 |
Robin_Watts | marcosw1: Right. I'll look at doing that. | 16:34.27 |
chrisl | henrys: the plan is (or was?) that the udebug etc targets would disappear when we're happy that the FAPI is "mature" enough | 16:34.54 |
marcosw1 | kens: I saved the settings and the option says: /NeverEmbed [ true ] | 16:35.09 |
kens | horrors | 16:35.32 |
henrys | onto alexcher email. Valgrind is way too slow for total coverage, were you thinking of a subset of file? | 16:35.45 |
chrisl | Oh, jeez, Adobe should be shot! | 16:35.50 |
ray_laptop | marcosw: intetesting. So it isn't a name type so it can't be confused with a font name | 16:35.58 |
marcosw1 | kens: as opposed the standard settings which says: /NeverEmbed [ true /Arial-Black /Arial-BlackItalic ... ] | 16:36.01 |
ray_laptop | that's even more clever that /NeverEmbed [ /All ] :-) | 16:36.20 |
henrys | chrisl:okay we can stick with that. | 16:36.27 |
kens | crap setting | 16:36.27 |
ray_laptop | so no list impiles * | 16:36.55 |
kens | apparently | 16:37.04 |
| and iots not how the documentation says it works either | 16:37.41 |
henrys | alexcher:and for static analysis we have clang and everyone should be looking at those. Was there something else we should do. | 16:37.48 |
| ? | 16:37.49 |
ray_laptop | it's not a lot different to using fonts that are protected, so cannot be embedded | 16:38.12 |
| henrys: alexcher did mention running valgrind in the 'spare time' on the cluster machines | 16:38.45 |
henrys | marcosw, alexcher:it would be nice though to use the cluster for other things. valgrind and coverage come to mind. | 16:38.55 |
ray_laptop | alexcher: but who is going to look at all the valgrind logs -- you ? | 16:39.06 |
alexcher | henrys: we need to how imortant is to clear all clang warnings. | 16:39.10 |
Robin_Watts | We could have a background task that picked a random file, and a random device, and valgrinded it. Clean runs wouldn't be reported, non-clean runs would go into a pile. | 16:39.58 |
ray_laptop | with the massive clang output, we need a way to tell us all that a certain warning has already been reviewed and is not a real problem. How do we do that | 16:40.12 |
alexcher | ray_laptop: idealy, one whose commit introduces it. | 16:40.14 |
marcosw1 | henrys: I think we should be running folding @ home on the spare cluster nodes :-) | 16:40.27 |
Robin_Watts | Possibly we should restrict the choice of files to be the ones that are known to be indeterminate. | 16:40.57 |
ray_laptop | Robin_Watts: but doesn't valgrind always report some junk ? | 16:41.13 |
henrys | marcosw1:well we are going to pump up miles' office with nodes right? | 16:41.19 |
marcosw1 | ray_laptop: a clang warning whitelist in the repository? | 16:41.21 |
Robin_Watts | ray_laptop: I don't believe so. | 16:41.41 |
henrys | marcosw1:I'd like a weekly coverage run for the tests. It seems like that shouldn't be difficult to add. | 16:42.22 |
ray_laptop | marcosw: and a method to give us a clang list with whitelisted items deleted | 16:42.24 |
chrisl | Robin_Watts: there are some GC related uninitialised variables that valgrind throws up most of the time | 16:42.25 |
alexcher | ray_laptop: Valgrind often reports problems in GC. There's a bug about it. | 16:42.27 |
marcosw1 | henrys: Yes, my plan is to move the 3 that are in my garage when miles upgrades his internets connection. That will mean 8 at his office (4 in my home, 4 at alex's, 2 at yours, and 1 at ray's). | 16:42.34 |
| for a total of 19 (seems a shame to make it an even 20). | 16:43.02 |
Robin_Watts | chrisl: Can we fix them ? | 16:43.04 |
ray_laptop | alexcher: that's what I thought. the GC chunks align objects in the chunks, leaving spaces that are technically not intitalized | 16:43.42 |
chrisl | Robin_Watts: probably. I looked at them briefly a while back - but initialising them to either of their allowed values caused problems which I didn't have time to track down | 16:44.00 |
marcosw1 | chrisl and Robin_Watts: the routine valgrind warnings aren't a big deal, I can easily ignore them in the test software. | 16:44.04 |
| speaking of valgrind, I wonder how many of the cluster nodes have it installed... | 16:44.20 |
Robin_Watts | ray_laptop: Right, but valgrind will only report if we actually use those values. | 16:44.25 |
chrisl | marcosw1: true, but it would be nice to fix them | 16:44.30 |
Robin_Watts | copying them around isn't a problem. | 16:44.37 |
henrys | anyway why don't we all just agree to look at all our warnings and report next week what can and can't be done with them. | 16:44.39 |
ray_laptop | marcosw: OK. then the valgrind output would be more useful when new stuff shows up | 16:44.43 |
henrys | alexcher:the other item in your email platform testing I think is covered by the bug we made for chrisl about platform releases, yes? | 16:45.27 |
ray_laptop | doesn't remember where the clang report lives (it was so full of noise, I only look at the 'new warnings' on commits) | 16:45.43 |
alexcher | henrys: yes. | 16:45.48 |
henrys | ray_lapton:search email for clang | 16:46.11 |
chrisl | henrys, alexcher: I think we have to live with the fact that there will always be platforms we can't test | 16:46.12 |
marcosw1 | the only problem I see with using the cluster nodes to run valgrind is that I'll have to add an "abort current job" option. Some of the valgrind runs will probably take hours and we don't want to slow down a commit/clusterpush run. | 16:46.43 |
ray_laptop | for alignment issues, we had suggested SPARC. Does Amazon offer sparc nodes ? | 16:47.08 |
marcosw1 | ray_laptop: nope, just intel | 16:47.19 |
alexcher | chrisl: Sure, but there are platforms that we can test but don't do this. | 16:47.28 |
chrisl | Actually, I should be able to run more tests on my Sparc in the future | 16:47.57 |
marcosw1 | chrisl and I both have sparc ultra 60 machines. We can run them in a small cluster :-) | 16:48.09 |
henrys | chrisl: agreed, IMHO a windows machine on the cluster - even if it is limited because output doesn't match in some configurations would be more useful than sparks and vax's | 16:48.21 |
ray_laptop | marcosw: can't the valgrind run with extremeely nice, and then the cluster master just stop feeding jobs to the nodes while a "real" run is done ? | 16:48.35 |
chrisl | marcosw1: I also have a blade 1000 sparc...... | 16:49.18 |
marcosw1 | ray_laptop: that might work. I'll run some tests. | 16:49.27 |
| chrisl: great, our sparc cluster has already grown by 50%. | 16:49.47 |
chrisl | marcosw1: yay, it will only take 18 months to run a cluster test! | 16:50.13 |
henrys | anyway well past end of meeting. Had a lot of stuff this time. | 16:50.30 |
marcosw1 | kens: do you have a canonical glyph bug that I can make 693700 a duplicate of? | 16:51.06 |
kens | ther'e several around, don;'t know numbers offhand | 16:51.23 |
| check for enhancements | 16:51.52 |
marcosw1 | kens: will do. | 16:51.57 |
chrisl | marcosw1: there is the issue of power consumption, too - these SPARC machines draw quite a bit more juice than modern PCs....... | 16:51.57 |
marcosw1 | chrisl: and are really loud. | 16:52.17 |
chrisl | Yeh | 16:52.25 |
marcosw1 | henrys: speaking of loud, my new (used) MacPro 3,1 is never very loud, even when running a cluster regression. Didn't you comment once on your MacPro 4,1 fans making noise during a cluster run? Or is that just your x6 machine? | 16:53.29 |
henrys | marcosw1:would it be possible to generate that huge coverage report you presented at the meeting years past on say a weekly basis. I'd like to keep up with what the tests hit. | 16:53.34 |
| no henrysx6 and if it weren't scattered about in pieces that might help ;-) | 16:54.22 |
kens | marcosw try #690393 | 16:54.36 |
| and #690469 | 16:54.58 |
marcosw1 | henrys: If I recall the coverage analysis is pretty slow to run. I'll rerun it and see how long it takes. | 16:54.59 |
henrys | you've also got the cppcheck stuff now too. | 16:55.30 |
Robin_Watts | coverage analysis = cluster checksum processing, right? | 16:56.03 |
| oh, no, this must be something else? | 16:56.31 |
marcosw1 | Robin_Watts: good point, I only need to run coverage analysis when files change their md5sum. | 16:56.58 |
| wait, maybe that doesn't work. a change in the source could alter the coverage without changing the output... I'll need to think about this. | 16:58.34 |
| henrys: sorry, I missed something, what cppcheck stuff? | 16:59.07 |
henrys | marcosw1:you have cppcheck reports in http://marcos-artifex.homeip.net:8080/artifex/master/ along with the other reports | 16:59.43 |
Robin_Watts | debugbin/gs -sDEVICE=tiffscaled -dDownScaleFactor=3 -r600 /mnt/hgfs/artifex/ghostpcl/tests_private/comparefiles/Bug690025a.pdf <- That gives 'undefinedfilename' as you'd expect cos we don't have a -o there. | 16:59.45 |
| bin/gs -sDEVICE=tiffscaled -dDownScaleFactor=3 -r600 /mnt/hgfs/artifex/ghostpcl/tests_private/comparefiles/Bug690025a.pdf <- That SEGVs | 17:00.03 |
henrys | pcl is clang, cpp, gcc, and scan-build warning clean the way I read these reports. | 17:01.00 |
| marcosw1:code coverage would be fast if it could be distributed and the reports merged. I don't thin the coverage files are that large. | 17:03.41 |
marcosw1 | henrys: yes, pcl is clean. but I don't understand your comment "you've also got the cppcheck stuff now too". Was that not mean for me? | 17:06.01 |
henrys | I didn't know you were running cppcheck and I was pointing out you did for others that didn't know. | 17:06.52 |
marcosw1 | sorry, I thought you meant that I needed to do something to change cppcheck. | 17:07.56 |
| also, you are probably right, distributed coverage should be reasonably fast. | 17:08.38 |
kens | OK time to go cook, night all | 17:13.32 |
henrys | mvrhel_laptop: I was going to ask at the mupdf meeting if there are any issues with you starting on CM in mupdf other than you are working on the windows viewer? | 17:18.17 |
mvrhel_laptop | henrys: no issues. I will review how CM is done in mupdf now and come up with a proposal | 17:19.27 |
henrys | great | 17:19.40 |
Robin_Watts | mvrhel_laptop: At the moment, every colorspace has a to_rgb and a from_rgb function. | 17:20.59 |
| And conversions are done using them. | 17:21.12 |
| I suspect that will need to redone to cope with things like separations. | 17:21.27 |
mvrhel_laptop | Robin_Watts: ok. I have a few test files that have all the color spaces. I will step through and see what is going on | 17:22.23 |
Robin_Watts | Also, I added 'fz_find_color_converter' a while ago. | 17:22.50 |
mvrhel_laptop | ok | 17:22.59 |
henrys | another mupdf issue - we should look into reflow on these ubuntu mobile devices. That could be an important factor in which viewer to use. | 17:23.02 |
| I mean which viewer is chosen as the default on the device. | 17:24.44 |
ray_laptop | mvrhel_laptop: I found a (long standing) bug in some PS tests. The job gets an error and prints an error message, but we ignored the error. I am going to assign it to me (since it only happens in clist mode), but cc you. I'd appreciate your comments | 17:25.17 |
mvrhel_laptop | ray_laptop: ok | 17:25.29 |
henrys | when mvrhel_laptop and I go to cupertino for the summit it would be nice to have an answer for reflow or at least a plan. | 17:26.36 |
mvrhel_laptop | Robin_Watts: you are the reflow guru...? | 17:27.05 |
Robin_Watts | henrys: MuPDF has a text extraction device that returns the page as a set of spans/lines/blocks per page (with a style sheet) | 17:27.38 |
| My latest changes extract those a bit more smartly than before, and there is a bit more information in there than before. | 17:28.35 |
| But essentially people are free to do what they want with the information. | 17:28.52 |
henrys | right, we need to look at what the platform offers and see if we can use that as nicely as we do on android. | 17:29.17 |
Robin_Watts | We have code that dumps those extracted structures to HTML, and that's what we use on android. | 17:29.28 |
henrys | that's the question right? | 17:29.31 |
Robin_Watts | Right. | 17:29.38 |
| Either we can go with an HTML based solution, or we/they are free to code anything else they want. | 17:30.00 |
henrys | tkamppeter: ^^^ ? | 17:31.14 |
Robin_Watts | For those people that like puzzles, I've found a new really good one. | 17:32.03 |
henrys | anyway on my todo list I'll follow up with tkamppeter about that. | 17:32.23 |
Robin_Watts | Helen melted the fuse in my universal mains adapter, so it doesn't work, so I took it to bits. | 17:32.25 |
ray_laptop | blaming Helen, huh? | 17:33.08 |
kyak | so i am fighting to make "Hello World" work, this time on Linux and with UTF-8 (last time it was Windows and cp1251, which worked fine thanks for your help). I came across "u2ps" here: http://u2ps.berlios.de/ which worked pretty well for me | 17:33.48 |
ray_laptop | Robin_Watts: did you find a (melted) penny in the fuse ? | 17:33.53 |
henrys | hair dryer? | 17:33.55 |
Robin_Watts | ray_laptop: It wasn't my hair straightener that pulled too many amps :) | 17:33.59 |
kyak | you probably know that, i;m sharing just in case :) | 17:34.03 |
henrys | I was close | 17:34.15 |
ray_laptop | Robin_Watts: do you mean that your hair (notice singular) is naturally straight ? | 17:34.37 |
Robin_Watts | ray_laptop: I'd have to find it to check... | 17:34.51 |
ray_laptop | Robin_Watts: oops I forgot to add ;-) to my previous | 17:35.44 |
Robin_Watts | ray_laptop: I assumed it :) | 17:36.23 |
ray_laptop | mvrhel_laptop: OK bug 693718 added | 17:37.15 |
tkamppeter | henrys, are you investigating mupdf as PDF viewer/RIP on Ubuntu Touch? | 17:38.33 |
henrys | tkamppeter yes | 17:39.10 |
tkamppeter | henrys, is it from the interpreter side capable of all what GS (or Poppler) is capable of? | 17:40.02 |
henrys | tkamppeter: specifically we would like to know if the reflow on android is going to work? | 17:40.16 |
| tkamppeter: there is a project in the works to add gs color management to mupdf now. | 17:41.35 |
tkamppeter | henrys, what do you mean with reflow? Displaying PDFs without fancy layout, with font size of user's choice, in e-book-reader style? | 17:41.54 |
Robin_Watts | tkamppeter: Essentially yes. | 17:42.51 |
henrys | sorry I was called away | 17:43.26 |
Robin_Watts | You get the text (and if you are lucky relative font sizes), and the freedom to zoom in and out with the text reflowing to fit the screen but you lose the exact layout (and images etc) | 17:44.04 |
tkamppeter | henrys, color management is also great, AFAIK this is not available yet on mobile. | 17:44.31 |
marcosw | Robin_Watts: I was going to ask you or tor during the meeting but forgot. Is there a reason the default build for mupdf on Linux is 64 bit and on Mac OS X it's 32 bit? | 17:44.49 |
| This may be cause some indeterminisms in the mupdf cluster runs. | 17:45.12 |
Robin_Watts | marcosw: Hysterical raisans. | 17:45.16 |
tkamppeter | henrys, for MuPDF as RIP it should at least be capable of outputting CUPS/PWG Raster, PostScript, PCL 5c, PCL 5e, PCL-XL, perhaps also downleveled PDF. | 17:45.50 |
henrys | tkamppeter:and we are working on a printer solution for mupdf and hope to have at least a plan before the summit | 17:45.51 |
Robin_Watts | marcosw: I suspect because on linux if you do nothing you get 64bit, and on macos if you do nothing you get 32bit :) | 17:45.58 |
marcosw | Robin_Watts: no, it's an intentional check in the Makefile If you don't specify arch=amd64 you get a 32 bit build. | 17:46.49 |
tkamppeter | henrys, with this set of output formats we can support IPP Everywhere printers and many other networked IPP printers without need of model-specific drivers. | 17:47.07 |
marcosw | In Makerules: ifeq "$(arch)" "amd64" | 17:47.10 |
Robin_Watts | tkamppeter: MuPDF currently renders to pixmaps; we can output them as any form of raster you want. | 17:47.38 |
marcosw | only in the Max OS X section. | 17:47.40 |
Robin_Watts | marcosw: pass then. one for tor8. | 17:47.51 |
marcosw | okay, I'll email him. thx. | 17:48.00 |
Robin_Watts | tkamppeter: We can wrap pixmap output into PCL etc if you want, but it won't be high level PCL objects. | 17:48.33 |
henrys | tkamppeter:we are looking into it, but I think you should be taking a closer look at interactive features, they are going to be far more important. | 17:48.52 |
tkamppeter | Robin_Watts, so CUPS/PWG Raster, PCL 5c, PCL 5e, and PCL-XL would be no problem if the PCL output is raster style *probably most Windows drivers send raster PCL, too). | 17:49.20 |
Robin_Watts | We don't have a PS output solution currently, but we could do that by wrapping bitmaps too (PS isn't expressive enough for transparency etc, so in generality it will need to go to an image anyway) | 17:49.41 |
| tkamppeter: Indeed. | 17:49.52 |
| Architecturally MuPDF has a structure whereby we *could* do high level output. | 17:50.23 |
tkamppeter | Robin_Watts, yes, we should do PS this way then, perhaps even PDF downleveling by PDF-wrapped raster. | 17:50.47 |
Robin_Watts | We have partially written code to write pdf files out from any input format we support. | 17:50.58 |
vtorri | chrisl, i know, but i do something different than what is done in mupdf | 17:51.16 |
Robin_Watts | so we could do high level solutions later if required, but they are not immediately on our roadmap. | 17:51.19 |
| tkamppeter: Indeed. wrapping bitmaps is by far the easiest way in the short term. If you're happy with that, then that's great. | 17:51.38 |
vtorri | chrisl, and that does not solve the problem that the jbig2dec link on the official web page is broken | 17:51.42 |
tkamppeter | Robin_Watts, we only need to take care that the printers do well with bitmap jobs and do not run out of memory. | 17:52.20 |
Robin_Watts | tkamppeter: We can split the bitmaps into bands easily enough if that helps. | 17:52.48 |
chrisl | vtorri: what "official" web page? | 17:53.10 |
henrys | tkamppeter: what we were asking, is html going to work on the platform with reflow like it does on android. For example if we need to do native reflow we need to know that now. Is there a developers API we can look at yet? | 17:53.16 |
chrisl | vtorri: and whatever you do "different", why can't you use the jbig2dec that comes with mupdf? | 17:54.29 |
henrys | tkamppeter: what we've seen so far is nobody cares about printing they care about reflow, annotations, signature stuff like that. I can almost assure you the same experience when real users get to use this device | 17:54.52 |
vtorri | chrisl, http://jbig2dec.sourceforge.net/ | 17:55.48 |
| chrisl, it's our leader which decides | 17:56.05 |
| so i follow his desires :) | 17:56.20 |
chrisl | vtorri: but the code included in mupdf is more up to date | 17:56.36 |
tkamppeter | Robin_Watts, then we should do so to assure that the bitmap printing works. Will this also work with PostScript? | 17:56.56 |
vtorri | hmm | 17:56.56 |
chrisl | We *must* get rid of that sourceforge jbig2dec page :-( | 17:56.59 |
Robin_Watts | chrisl: That webpage is ours, I believe. And the pointer to the latest release is http://ghostscript.com/~giles/jbig2/jbig2dec/jbig2dec-0.11.tar.gz | 17:57.18 |
vtorri | chrisl, well, googlee gives that link first | 17:57.23 |
| so i follow it | 17:57.36 |
chrisl | vtorri: google can be wrong | 17:57.38 |
vtorri | chrisl, google is my friend, it can't lie to me ! | 17:57.54 |
chrisl | Robin_Watts: it may be "ours" but I have no access to it | 17:57.55 |
vtorri | :) | 17:57.56 |
chrisl | I guess we ought to do a jbig2dec release at some point..... | 17:58.35 |
vtorri | anyway, how can i know that this web page is not the "official" one ? | 17:58.39 |
tkamppeter | henrys, unfortunately, I do not know about a developers API for HTML reflow, but if MuPDF converts the PDF to HTML one can probably re-use libs of the web browser to display the HTML reflow. | 17:58.52 |
henrys | chrisl:another thing meeting stuff - do you think it is sensible to look for overlap between cups and our drivers and remove any of ours that are already covered by cups? | 17:58.54 |
Robin_Watts | vtorri: You're right. We should find some way of fixing it. | 17:58.55 |
chrisl | vtorri: I'm not blaming you | 17:59.05 |
| henrys: we'd need help from tkamppeter to do that | 17:59.21 |
Robin_Watts | tkamppeter: We *can* go to HTML. We can also go to something else. | 17:59.35 |
| HTML just happened to be easy for Android (and hopefully for iOS). | 17:59.53 |
vtorri | and about the release, yes | 18:00.08 |
Robin_Watts | but going to 'something else' may be better (faster, nicer results). | 18:00.10 |
vtorri | it is a good idea :p | 18:00.21 |
henrys | chrisl:isn't there just a printer database that we can look at? | 18:00.23 |
tkamppeter | Robin_Watts, HTML should be easily displayable by any OS, as there is no OS without browser. Aftyer that one could think about e-book formats as e-book reader functionality is also common on mobile OSes. | 18:01.03 |
chrisl | henrys: but some drivers support a range of printers | 18:01.07 |
| vtorri: it hardly comes as a priority since AFAIK, only Ghostscript and mupdf use jbig2dec | 18:01.38 |
Robin_Watts | tkamppeter: AGES ago, I had code to go from mupdf -> ebooks. | 18:01.39 |
henrys | chrisl:yeah I guess that is true, maybe tkamppeter could help out, I fear there is a lot of duplication and we could dump some of these very dated devices. | 18:02.09 |
vtorri | chrisl, and me !! i use jbig2dec ! | 18:02.47 |
chrisl | henrys: that would be good - I reckon some of them don't work properly any more! | 18:02.50 |
| vtorri: for what? | 18:02.55 |
vtorri | actually, i also plan to use it in a multi document rendering library | 18:03.12 |
tkamppeter | chrisl, for printer drivers one could even let MuPDF simply output CUPS/PWG Raster and then add several rasterto.... filters (rastertopcl, rastertopxl, rastertops, ...), at least rastertopcl is available in some forms in cups and cups-filters. | 18:03.30 |
chrisl | vtorri: That will support jbig2 files? | 18:03.43 |
tkamppeter | chrisl, I could open some GSoC project ideas to perhaps get rastertops and rastertopxl. | 18:04.07 |
vtorri | chrisl, i try to support as much images as i can | 18:04.20 |
| images formats* | 18:04.33 |
chrisl | tkamppeter: erm, I suspect you're not really talking to me, there | 18:04.37 |
| vtorri: jbig2 images are pretty darned rare! | 18:05.08 |
Robin_Watts | tkamppeter: rastertops, rastertopcl, rastertopxl etc sound like good ideas. | 18:05.12 |
vtorri | chrisl, :) | 18:05.20 |
tkamppeter | chrisl, sorry, it is for henrys. | 18:05.29 |
chrisl | tkamppeter: np | 18:05.36 |
Robin_Watts | And they sound more 'cupsish' than 'mupdfish' | 18:05.48 |
chrisl | ray_laptop: ping | 18:05.55 |
tkamppeter | Robin_Watts, this is a form of decoupling RIP and printer driver, MuPDF generates a universal bitmap, PWG/CUPS Raster and the rasterto... filter wraps the bitmap appropriately. | 18:07.12 |
ray_laptop | chrisl: pong | 18:07.16 |
chrisl | ray_laptop: your listed as being on the sourceforge jbig2dec project - if you could add me to it, I could sort out the web page(s) | 18:07.54 |
| s/your/you're | 18:08.00 |
ray_laptop | chrisl: OK. I'll see if I can still get in | 18:08.14 |
tkamppeter | Robin_Watts, but as current CUPS filters pull info from PPD files it is perhaps better to let the core filters come with MuPDF, but as seperate executables and let MUPDF also ship CUPS wrappers. | 18:08.37 |
Robin_Watts | tkamppeter: Right. | 18:09.04 |
chrisl | ray_laptop: thanks - I'm trying to see if there's a way I can send you request via sf - if there is, it's not obvious! | 18:09.40 |
Robin_Watts | If you want to minimise memory use we'd probably want mupdf to render to display list, then repeatedly render that display list in bands, and convert each band of output at a time. | 18:09.59 |
| hence it may be best to have the filters more tightly integrated with MuPDF. | 18:10.22 |
tkamppeter | Robin_Watts, exchange format between MuPDF and driver should be PWG Raster as it is the only free software industry-standardized device-independent print raster format. | 18:10.43 |
docampo | Hi, I am working on Android with muPDF. I just replaced the bottom SeekBar to navigate through the pages, with an HorizontalScrollView that contains thumbs of each page. When clicking on each one, you go directly to the page. The thing is that, for some reason, the onClickListener on the thumb is not being fired. I'm sure it is being set, but I can't figure out what is happening. Is threre something I am missing ? | 18:11.01 |
Robin_Watts | tkamppeter: Right, but if I have a 600dpi A4 color printer that i want to drive, do we really want mupdf to have to produce a large uncompressed image which will then get converted? | 18:11.53 |
docampo | I know that my question without checking the code could sound a bit ridiculous but I was wondering that maybe you know some detail I am missing. | 18:12.29 |
Robin_Watts | 600*600*4*12*8 = 135 Meg? | 18:12.56 |
chrisl | Doesn't PWG allow compression? | 18:13.23 |
Robin_Watts | chrisl: So we render into uncompressed bands, compress those bands into the PWG file, then the raster stuff needs to uncompress again in order to work with it? | 18:14.25 |
| better for mupdf to render into uncompressed bands, and call the code to produce the appropriate output directly from those band buffers. | 18:15.06 |
| (IMHO) | 18:15.34 |
chrisl | Robin_Watts: I guess you could write the raster data to a pipe, and have the filter consume/compress from that | 18:15.47 |
| That's that traditional "unix way" after all | 18:16.13 |
Robin_Watts | chrisl: not sure whether pipes on a mobile device are a great idea, but yes, it could be done like tnat. | 18:16.15 |
chrisl | Robin_Watts: why would a pipe be bad on a mobile device? | 18:16.52 |
Robin_Watts | I could be wrong here... but if one end of a pipe runs faster than then other, then the pipe gets large, and normally the contents get put to disk, right? | 18:17.45 |
chrisl | Robin_Watts: normally the sending process would block | 18:18.05 |
Robin_Watts | fair enough. | 18:18.14 |
chrisl | It does depend on the implementation, of course...... | 18:18.35 |
Robin_Watts | tkamppeter: It's worth saying, that mupdf is at heart a set of libraries for manipulating/rendering PDF/XPS/other files. | 18:19.01 |
| The apps (such as mudraw) are thin layers on top of this. | 18:19.16 |
| So if mudraw doesn't do exactly the job you want, it's trivial to do a mucups (say) that does exactly what you want with banding etc. You're not limited to working with exactly the tools we currently supply. | 18:19.58 |
tkamppeter | Robin_Watts, I was thinking about modularization and standard interfaces so that one can easily add extensions (like new drivers) in the future, but on the other side with IPP Everywhere the need of printer drivers will go away. IPP Everywhere printers are required to support PWG Raster as input format natively, my selection of other formats is for supporting common legacy printers. So most probably there is no need of easy addition of n | 18:22.12 |
| ew formats. | 18:22.12 |
Robin_Watts | tkamppeter: I am sure we can meet the needs of 'easy addition of new formats' while still getting 'tight integration to minimise memory/CPU usage' with a bit of thought. | 18:24.04 |
| but GSoC applications seem like a good idea to me. | 18:24.37 |
henrys | ipp everywhere supports pdf so why would we need to send a raster? | 18:24.53 |
ray_laptop | chrisl: what's your SF username ? | 18:25.10 |
chrisl | ray_laptop: cliddell | 18:25.19 |
ray_laptop | (I finally got back into SF) | 18:25.28 |
| chrisl: thanks. just a minute... | 18:25.37 |
henrys | oh maybe pdf is optional | 18:25.39 |
Robin_Watts | I'd imagine dumb printers would require a host to convert pdf, but would cope with simple raster itself. | 18:26.21 |
ray_laptop | chrisl: OK. You should now be in there as an "Admin". Give it a whirl | 18:28.55 |
chrisl | ray_laptop: given it just prompted me to "upgrade my project", I'd say I'm in! Thank you. | 18:29.25 |
| I'll do some damage on there tomorrow :-) | 18:30.06 |
henrys | tkamppeter: I assume ubuntu touch will have something like the apple store or google play correct? So if we aren't the default user we could let users at least download and install mupdf if they chose to use it. Is that right? | 18:31.03 |
| s/default user/default viewer/ | 18:31.22 |
ray_laptop | mvrhel_laptop: that bug 693718 is quite strange. It works OK (in clist mode) at 73 dpi, fails at 72 and 71 then works again at 70 and 69 dpi :-/ | 18:31.41 |
| mvrhel_laptop: I'm looking at what the different path take are... | 18:32.28 |
| s/take/taken/ | 18:32.37 |
henrys | marcosw:every so often linux "migration" processes take over all my cpus - are you seeing that on the other linux boxes? This happens when the machine appears to be inactive. | 18:32.39 |
mvrhel_laptop | ray_laptop:ok I have not had a chance to look at it yet | 18:32.55 |
tkamppeter | henrys, yes. On the desktop we have already the Ubuntu Software Center and on the mobile there will be such thing for sure. | 18:32.57 |
henrys | tkamppeter: thanks | 18:33.21 |
tkamppeter | henrys, did you compare the memory footprints/resource consumption of the three free software PDF renderers GS, Poppler, and MuPDF? How do they compare? | 18:34.16 |
ray_laptop | mvrhel_laptop: don't bother. I'll hunt you down if I need advice :-) | 18:34.38 |
henrys | tkamppeter: no I haven't done that, one for somebody's todo list | 18:36.08 |
Robin_Watts | has his finger on his nose. | 18:36.33 |
henrys | we can quickly get out latest numbers, can you give us poplars? | 18:37.13 |
| popplers - colloquy changes my spelling, for the best usually. | 18:37.56 |
tkamppeter | henrys, unfortunately not, but for establishing MuPDF as standard PDF renderer on Ubuntu Touch I must know what are the advantages of MuPDF against the others. | 18:38.34 |
henrys | we really aren't considering GS in this domain, no viewer. | 18:38.53 |
Robin_Watts | Such tests are meaningless unless you specify what banding to use, and standardise on a given document (with transparency etc) | 18:38.58 |
| Also, mupdf takes advantage of a however much memory you tell it to to cache things in, so subsequent viewing operations are fast. | 18:39.47 |
| marcosw: I believe the tiffscaled indeterminisms should be solved now. | 18:41.17 |
tkamppeter | henrys, Robin_Watts, AFAIK Ubuntu Touch uses Poppler currently, so what I need to know is whether MuPDF is better than Poppler for all intended tasks, as we have to decide for one PDF renderer. | 18:41.53 |
chrisl | Grrr, debugger just crashed - calling it a night there........ | 18:45.19 |
henrys | tkamppeter:so it sounds like what you need is somebody to install ubuntu touch on a nexus 7 or some other android device and then get mupdf running and compare. How stable is this platform? Is it something we could even do? | 18:47.20 |
| bbiab I'll read the logs | 18:51.18 |
tkamppeter | henrys, there are instructions out there on https://wiki.ubuntu.com/Touch | 18:51.21 |
henrys | tor8 we are discussing getting mupdf to run on https://wiki.ubuntu.com/Touch, I wonder if sebras would like to give that a try on a consulting basis? | 19:02.48 |
Robin_Watts | tkamppeter: How involved are you in the poppler/mupdf decision? | 19:03.00 |
| (or perhaps I should say "would you be"?) | 19:03.15 |
| We are clearly interested in going for this, but before we sink hours/days/weeks work into this, we'd probably like to be sure that there aren't other factors in play here that would prohibit us ever getting past first base here. | 19:04.08 |
henrys | OTOH it may be better for us to wait for ubuntu touch to mature and then just produce and app for it. This looks terribly work intensive where ubuntu touch is now. | 19:04.36 |
| reading the link. | 19:04.56 |
Robin_Watts | It would be extremely useful for us to have a concrete "this is what we would need to be able to do with mupdf in order for us to adopt it" spec to work to. | 19:05.11 |
| I understand that such a spec will not be something that you just have lying around though. | 19:05.57 |
tkamppeter | Robin_Watts, henrys, my concerns are simply to get a lightweight (memory/CPU/battery) solution to render PDF inut files for both screen display and printing (to have only one PDF interpreter on the mobile device). | 19:06.29 |
Robin_Watts | tkamppeter: Right. And we believe that mupdf is a really good contender for that. | 19:06.53 |
| certainly I've not seen poppler being used for android apps, where we know mupdf is used for many. | 19:07.35 |
| (I'm not saying it's not used, just that I haven't seen any in my travels that say "we are poppler based") | 19:08.08 |
henrys | tkamppeter: and you are part of (weigh in on) the printing part of the decision, what other players are involved? Is the pdf viewer being handled entirely by the printing group? | 19:08.57 |
tkamppeter | henrys, I am only responsible for the printing part, my co-workers of the desktop team are doing the PDF viewer. | 19:14.54 |
henrys | well if there is someone else we should talk to, please let us know, we are happy to do that. | 19:15.36 |
Robin_Watts | tkamppeter: Is it worth us starting an email conversation to involve everyone on this? | 19:17.45 |
| We want to do this, but it'd be bad for us to sink huge amounts of time into it only to find that the desktop team aren't interested in what we have to offer. | 19:18.36 |
| A few emails now to get 'buy in' from everyone could safe both us and you endless pain later. | 19:19.01 |
| s/safe/save/ | 19:19.31 |
tkamppeter | Robin_Watts, henrys, perhaps one of you could present MuPDF as possible mobile PDF renderer on the https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss list. | 19:22.23 |
Robin_Watts | tkamppeter: If that's the best forum for this, then absolutely, I think we should do that. | 19:23.24 |
marcosw1 | alexcher: when you have a sec could you install valgrind on alex_i3770? I believe that's the only machine that doesn't have it installed. | 19:23.31 |
henrys | marcosw1:Macpro will likely be a problem for this | 19:24.10 |
Robin_Watts | marcosw1: In case you didn't see me bibble earlier, the tiffscaled stuff should be done now. | 19:24.23 |
tkamppeter | Robin_Watts, or you join #ubuntu-desktop on Freenode, preferably during the business hours of Europe. | 19:24.56 |
Robin_Watts | tkamppeter: Will do. | 19:25.36 |
mvrhel_laptop | bbiaw | 19:31.28 |
marcosw1 | henrys: yes, I wasn't going to run valgrind on your or my macpro. | 19:38.00 |
| Robin_Watts: thanks. that was fast. | 19:38.10 |
Robin_Watts | marcosw1: And embarassing too, given the error I found. | 19:38.29 |
tkamppeter | Robin_Watts, henrys, and anyone in charge of the ps2write output device, the discussion about the PDF renderer for mobile arrived at the point how to print on PostScript printers and there we came to the conclusion that the best is to simple send bitmaps in bands as this is less resource-consuming for mobile, does not hit bugs of printers so easily, copes better with the transparency bloat of Cairo's PDF output, and so I suggested to add | 19:59.52 |
| an option to ps2write to generate bitmap-band PS, or to create a new PS output device. | 19:59.52 |
tsdgeos | tkamppeter: where is that discussion of pdf/ps rendering for ubuntu mobile happening? | 20:03.12 |
tkamppeter | tsdgeos, on #ubuntu-touch on Freenode | 20:05.42 |
| tsdgeos, the discussion started here and moved over to #ubuntu-touch and the Ubuntu Touch guys did not settle on a PDF renderer yet. Seems that MuPDF has good chances there. | 20:14.03 |
| Robin_Watts, how do I do reflow on the Android version of MuPDF? | 20:21.11 |
henrys | there is a button at the top with lines the ends of which are slanted. that toggles on and off reflow | 20:23.40 |
| bbiab | 20:23.54 |
alexcher | marcosw1: Valgrind is now installed on alex_i3770. | 20:24.28 |
Robin_Watts | henrys: OK. discussions with the ubuntu guys started. | 20:57.38 |
| There is to be a meeting in #ubuntu-touch-meeting tomorrow at 4:30PM EST where doc viewers are to be discussed. I'll try to be online for that. | 20:58.19 |
ray_laptop | Robin_Watts: GREAT email !! | 21:01.17 |
| Robin_Watts: Did Scott-san see this ? This would be good for him to work into a form suitable for his emails (but NOT without edit for purpose) | 21:03.16 |
Robin_Watts | ray_laptop: No, scott won't have seen that. | 21:03.36 |
ray_laptop | Robin_Watts: I wasn't sure why I had seen it. (you must have Bcc'd us) | 21:04.08 |
| which I appreciate | 21:04.15 |
| if you cc'ed support, Scott _would_ now see it. But not tech | 21:04.54 |
Robin_Watts | I BCC'd tech | 21:05.22 |
ray_laptop | and staff picks up him and Miles. | 21:05.32 |
| If you didn't, I think sending a copy to Scott and Miles would be good. | 21:06.03 |
Robin_Watts | I will forward it. | 21:07.35 |
ray_laptop | Robin_Watts: it's so good I think we (the royal "we") need to craft it into the mupdf.com website. | 21:07.36 |
| I have to pick my daughter up from school. bbiaw | 21:08.20 |
tkamppeter | Robin_Watts, we need to tell the student that he has to do so and if he agrees with it. For Google it should be no problem as the code gets published as free software. Is it a problem that a copy of the code has also to reside on Google's servers? | 21:09.11 |
Robin_Watts | not at all. | 21:09.31 |
| henrys: tkamppeter is suggesting that we/he could apply to Google Summer of Code to get students to write some of the missing bits of code for us. | 21:13.43 |
| In particular things like raster2pcl, raster2pxl etc would seem to be nice separable tasks. | 21:14.08 |
| If one was feeling really keen they could even look at doing a psimgwrite device (that would render to bitmap bands and wrap those as images into a PS stream). | 21:15.02 |
| I said that we'd need to be sure that the student was happy to copyright-assign to us at the end for our licensing. | 21:15.35 |
| Anyone have any thoughts on this? | 21:15.46 |
| ray_laptop: (For the logs) Forwarded to Scott/Miles. | 21:17.49 |
| I'm just having a quick look at some of these valgrind warnings. | 21:25.10 |
| One of them is caused by us marking through gs_state. When it reaches the halftone pointer, we have the problem. | 21:25.59 |
| gs_state->halftone = 0x4851094 | 21:26.21 |
| and valgrind is upset by if (o_is_unmarked(ptr)) where ptr = 0x4851088 | 21:27.42 |
| The contents of gs_state->halftone seem entirely believable though. | 21:28.58 |
tkamppeter | Robin_Watts, where does one report bugs in MuPDF? | 22:08.34 |
| Robin_Watts, http://bugs.ghostscript.com/show_bug.cgi?id=693719 | 22:20.19 |
henrys | Robin_Watts:much rather hire someone like sebras if he is interested in doing it. | 22:34.50 |
| or zeniko might want to make some money and do it. | 22:38.35 |
ray_laptop | I found out what's going on with bug 693718 -- we have a pattern mask that ends up being all 1's and "gx_pattern_cache_add_entry" optimizes it away, confusing later code | 23:35.22 |
| there are 18 tests, all psdcmyk, that trip over this so I am sorely tempted to just rip out the "optimization" | 23:37.14 |
| the optimization has been in there since 1998 | 23:40.10 |
| Forward 1 day (to 2013/03/21)>>> | |