| | <<<Back 1 day (to 2015/09/30) | 20151001 |
| Robin_Watts | Ok, barring unexpected problems, electrical testing is done now. | 08:27.05 |
| | Morning tor8. | 09:37.49 |
| | Sorry, I had PC problems just after I spoke to you last night. graphics card was crashing the machine. | 09:38.05 |
| | can of air, plus WD40 later, and it seems to be working again. | 09:38.18 |
| | tor8: So, the reason I asked was because of bug 696146. | 09:42.38 |
| | That file is corrupted so that page 8 can't be read. | 09:42.57 |
| | When we try to read page 8, old versions of MuPDF just error out, and we get an empty page. We can then subsequently look at other pages. | 09:43.37 |
| | With newer MuPDFs, we do a repair when we hit the problem. | 09:44.08 |
| | This is a file that uses new style xrefs (object compression), so we end up creating a new trailer dict at the end without having a Root object. | 09:44.40 |
| | This means that all attempts to read from the file after that fail. | 09:45.00 |
| | I have some code to fix it here, whereby we look for 'Root' entries in any dicts we repair. | 09:46.06 |
| | The problem with *that* is that any objects we parse (such as the root object) don't have the 'doc' pointer set. | 09:46.34 |
| | So either we need to pass the doc pointer into pdf_parse_dict, or we need to shoehorn the doc pointer into the root object later. | 09:47.39 |
| | And that would need to be a recursive shoehorn, of course. | 09:48.03 |
| | How would you feel about a 'pdf_dict_get_no_indir' ? | 09:48.41 |
| | actually... why is that needed again? | 09:52.54 |
| | We do a pdf_parse_dict, so we know that we actually have a dictionary (not an indirect ref). | 09:53.18 |
| | Any call to pdf_dict_get on that dict will therefore be fine | 09:53.32 |
| | oh, but pdf name_eq might not be. | 09:54.24 |
| tor8 | Robin_Watts: should be safe if we preface all pdf_name_eq etc with !pdf_is_indirect | 09:58.12 |
| | like we do for the /Length pdf_is_int test | 09:58.39 |
| Robin_Watts | tor8: Yeah, I've just done that here :) | 09:59.52 |
| tor8 | right :) | 09:59.59 |
| Robin_Watts | So I'll have a commit for all this in a bit when I've tested it. | 10:01.01 |
| | OK, tor8, one commit on robin/master then. | 11:58.05 |
| | tor8: bug 696143. Sounds like one we should talk about. | 12:07.08 |
| tor8 | Robin_Watts: LGTM | 12:08.02 |
| Robin_Watts | I like the idea of generating the pdf-name-table.h in GEN rather than obj, but a) it has to work with all our builds, not just the makefile ones, b) how does that work for people that want to use mupdf as a lib etc. | 12:08.04 |
| tor8 | hm, yes, I've considered the same | 12:08.13 |
| Robin_Watts | tor8: Thanks. | 12:08.15 |
| tor8 | shouldn't be any different to how we currently generate cmap and font files in $GEN | 12:08.31 |
| | and the javascript prolog stuff is also generated in $GEN | 12:08.56 |
| | it's a bit messier for the header file though | 12:09.46 |
| Robin_Watts | $GEN is 'generated' rather than 'debug', right? | 12:09.56 |
| tor8 | yes | 12:10.18 |
| | the only problem as I see it is what to do about include/mupdf/pdf/name-table.h | 12:10.54 |
| | we could make sure to check in the generated name-table file and only regenerate manually | 12:11.40 |
| Robin_Watts | no, I think it's important we generate automatically. | 12:12.08 |
| tor8 | ideally we would want a script to grep through the source to generate resources/pdf/names.txt | 12:12.17 |
| Robin_Watts | Why is include/mupdf/pdf/name-table.h a problem? Dependencies in the makefiles? | 12:12.52 |
| tor8 | we can't easily move it to 'generated/', because it's needed as part of the public API | 12:13.15 |
| | source/pdf/pdf-name-table.h could be moved to $GEN though | 12:13.35 |
| | I wonder if we do some trickery with #define etc, if we could make include/mupdf/pdf/name-table.h the source file instead of resources/pdf/names.txt | 12:14.43 |
| | just make it a list of PDF_DEFINE_NAME(BaseFont) and that would expand to different things depending on where it's included | 12:15.23 |
| | and never have to auto-generate anything at all | 12:15.30 |
| Robin_Watts | You can't have one #define define another #define. | 12:16.02 |
| tor8 | and then for the public header, we expand to what is currently in the header | 12:16.18 |
| | and then another #define for making the actual string table | 12:16.27 |
| Robin_Watts | so we couldn't have PDF_NAME_3D be defined from PDF_DEFINE_NAME(3D) | 12:16.30 |
| tor8 | we could make static consts named PDF_NAME_3D from PDF_DEFINE_NAME though | 12:18.29 |
| | but then we're back to having a global variable for each PDF_NAME, just one containing the enum value | 12:19.12 |
| Robin_Watts | which is bad. | 12:20.17 |
| | cos compilers don't optimise those away. | 12:20.42 |
| tor8 | yeah. it won't work as neatly either. | 12:20.52 |
| | it'd be better to have actual pdf_obj without the magic enum values than that | 12:21.48 |
| | so it's not clear to me that we should do anything about this | 12:23.01 |
| | except to add both include/pdf/name-table.h and source/pdf/pdf-name-table.h to 'make clean' | 12:23.29 |
| | or 'make nuke' | 12:23.39 |
| | whichever clears out 'generated' | 12:23.43 |
| Robin_Watts | Yeah. | 12:23.45 |
| tor8 | oh, and .gitignore | 12:43.19 |
| henrys | chrisl: nice work with 532 lately, obviously a customer we want to keep happy | 14:10.01 |
| chrisl | henrys: Thanks - those reference counting ones have been.... um.... "interesting" :-( | 14:10.46 |
| henrys | you think there is more lurking? | 14:11.19 |
| chrisl | I think it would be unwise to assume otherwise | 14:11.52 |
| henrys | chrisl: I left a message for you in about norbert's bug if you are doing other stuff I can look again. | 14:14.00 |
| chrisl | henrys: I've been looking at the mispositioned glyphs - it's looking like a PITA | 14:14.34 |
| henrys | chrisl: well that means you had no problem isolating the glyph in the pcl. Of course a hack is always possible with explicit spacing up at the interpreter level if we can identify the data in some manner. | 15:06.20 |
| chrisl | henrys: I've got it both down to files with just 2/3 glyphs in them - the one with the problem, and one or two "sighter" examples. At the moment, I am bemused because I've hacked the FAPI code to pass the same numbers into gx_show_text_set_cache() that the cold code did, and I *still* get different, and *totally* wrong output :-( | 15:10.14 |
| henrys | chrisl: I'm very near to a pcl commit that will have the log message "destroyed the universe" ;-) | 15:20.12 |
| chrisl | henrys: Given the extent of the changes it must involved, probably not far from the truth! | 15:21.03 |
| henrys | the coverage links on the dashboard are 404'd anybody know where marcos moved that stuff? | 16:19.55 |
| Robin_Watts | I do not. | 16:37.43 |
| jogux | Ahha. a backlog of bugzilla emails just started to arrive :-) | 16:44.39 |
| mvrhel_laptop | ray brings up a good point in his email to Joann. Do you know anything about that henrys? | 17:55.08 |
| | I saw that Jasper just had asked a question to support a few days ago so that seems odd | 17:56.22 |
| | perhaps they have merged together | 17:56.43 |
| henrys | mvrhel_laptop: no I don't. | 18:08.55 |
| mvrhel_laptop | I think one bought the other | 18:09.14 |
| | And likely there was a loss of an account that way | 18:09.34 |
| henrys | mvrhel_laptop: you could ask MQ him how we can build a profile configuration on the target... the command line incantation etc. that's all I can think to add. | 18:09.59 |
| mvrhel_laptop | henrys: oh good one | 18:10.30 |
| | thanks | 18:10.33 |
| henrys | and we are willing to pay them real engineering hours to do the analysis and tell us where the bottlenecks are. | 18:11.11 |
| mvrhel_laptop | oh that might be interesting | 18:12.08 |
| henrys | if they want a more partner like arrangement ... | 18:12.28 |
| mvrhel_laptop | fredross-perry: Just sent you an email with some profiles for testing | 18:12.38 |
| fredross-perry | thanks mv | 18:13.12 |
| henrys | mvrhel_laptop: there could be a mess of quirky stuff that they've already tripped over and it could save us a lot of work | 18:13.35 |
| mvrhel_laptop | yes | 18:13.42 |
| Robin_Watts | mvrhel_laptop: If they can't supply boards, a remote login to a board might do nicely. | 18:14.07 |
| henrys | Robin_Watts, mvrhel_laptop: especially with ray needing a little time that would be nice. | 18:14.38 |
| mvrhel_laptop | Robin_Watts: right. he did not think getting a board would be an issue. would it be worthwhile getting more than one? | 18:14.46 |
| | one for Robin_Watts one for Ray | 18:15.10 |
| | not sure if Robin_Watts has time | 18:15.28 |
| | I wonder if it would be worthwhile me having one here | 18:15.36 |
| henrys | mvrhel_laptop: I didn't want to volunteer him but that sounds right to me. | 18:15.37 |
| Robin_Watts | I was thinking the same :( | 18:15.41 |
| mvrhel_laptop | then I could always drag MQ over to my house.... | 18:15.55 |
| Robin_Watts | If we're seriously going to be aiming for optimisations on ARMs, then I'd like to be involved. | 18:16.15 |
| mvrhel_laptop | Robin_Watts: yes that makes sense | 18:16.24 |
| henrys | 3 boards ;-) | 18:16.31 |
| mvrhel_laptop | yes. maybe.... | 18:16.36 |
| | ok. need to run to car shop to pick up car. only took them 2 hours so hopefully its not going to be expensive.... | 18:17.56 |
| Robin_Watts | mvrhel_laptop: "Mr Vrhel, we need to special order a part in. It'll take a while, so there is no point in you leaving your car here" | 18:18.33 |
| mvrhel_laptop | that would be my typical luck | 18:18.45 |
| | bbs | 18:18.52 |
| Robin_Watts | reboot | 19:38.19 |
| rayjj | sorry, forgot to startup Chatzilla after a reboot. | 20:54.29 |
| | More than one board from M would be good, but if we can correlate performance of rendering a bitmap between a Pi and their board, then h/w is readily available | 20:55.25 |
| | I haven't checked, but are there Pi (or other vendor) boards/chips since the Pi "B" that I have ??? | 20:56.04 |
| | (700 MHz, single core, 256Mb ram, SD card storage) | 20:57.07 |
| Robin_Watts | There is a Pi 2 out now. | 20:57.17 |
| jogux | there's been at least one new beaglebone since the Pi 'B' too | 20:59.44 |
| qstpp | is there a way to start mupdf in fullscreen in Linux? | 21:12.43 |
| rayjj | I'm setting up my Pi "B" on a static IP. I can set up "user" accounts for whoever wants to play with it. It is at 100 dot 9 dot 62 dot 164 -- let me know if you want and I will set up an account with your ssh authorized_keys from casper | 21:17.23 |
| | s/I'm setting/I've set/ | 21:17.37 |
| | (I started the line before doing it) :-) | 21:17.53 |
| | my next step is to update ghostpdll and mupdf and rebuild them | 21:22.49 |
| | but first... I have to pick my kids up from school ... | 21:24.41 |
| | bbiab | 21:24.44 |
| | I'll check the logs to see if anyone wants an account on "raspberry" (not a real name on ghostscript.com -- yet) | 21:25.27 |
| mvrhel_laptop | I think most of us have a raspberry pi | 21:25.58 |
| | fredross-perry: are you around? | 22:13.34 |
| fredross-perry | yes | 22:13.42 |
| mvrhel_laptop | fredross-perry: is the gsproof / mupdf apk in your public html the one I should be using to check out the issue henry was seeing? | 22:14.50 |
| | for some reason I can't open any files with it | 22:14.58 |
| fredross-perry | yes, probably. | 22:15.26 |
| mvrhel_laptop | ok | 22:15.36 |
| fredross-perry | Do you have a device like his? | 22:16.01 |
| mvrhel_laptop | I have a nexus 10 | 22:16.13 |
| | everytime I try to open a file it says "Unfortunately MuPDF has stopped" | 22:16.30 |
| fredross-perry | Any file? | 22:16.38 |
| mvrhel_laptop | any file | 22:16.57 |
| fredross-perry | hmmm. | 22:17.04 |
| mvrhel_laptop | the list of files comes up | 22:17.08 |
| | I pick one | 22:17.18 |
| | and the app stops | 22:17.28 |
| | with that notice | 22:17.35 |
| | let me shut this thing down and restart | 22:17.50 |
| | maybe something is wacked | 22:18.03 |
| fredross-perry | Also try a dead simple small file. | 22:18.55 |
| mvrhel_laptop | I did | 22:19.15 |
| | so the one from the store is fine | 22:19.59 |
| | Ok. and it appears that the ListBox item is not properly supported in our store version which I also wanted to test. I will open a bug about that one | 22:21.00 |
| | Let me uninstall the store version and reinstall the one from your public_html | 22:21.26 |
| | same thing | 22:22.25 |
| fredross-perry | what vintage is your OS? | 22:27.17 |
| | My Nexus 7 is 5.1.1 | 22:28.05 |
| mvrhel_laptop | hold on | 22:33.25 |
| | 4.2.2 | 22:33.57 |
| | Maybe I should update.... | 22:34.02 |
| fredross-perry | related to PDF_WIDGET_TYPE_LISTBOX? | 22:34.17 |
| mvrhel_laptop | oh no that is a different bug | 22:34.32 |
| fredross-perry | well, maybe not update, since youâre manifesting (ha!) an issue that users may see. ?? | 22:34.38 |
| mvrhel_laptop | too late.... | 22:34.51 |
| fredross-perry | Sigh. | 22:35.03 |
| mvrhel_laptop | It is just going to 4.3 though | 22:35.19 |
| | So perhaps it will have the same issue | 22:35.33 |
| | have to run daughter back to get her homework | 22:35.50 |
| | bbiab | 22:35.52 |
| fredross-perry | cheers | 22:36.30 |
| mvrhel_laptop | ok with that update it works.... | 22:58.14 |
| | checking if I get the drop out tiles now | 22:59.12 |
| fredross-perry | Youâll get an immediate crash like that if the mupdf so is the wrong arcitecture. The version I built is armeabi-v7a. | 23:07.08 |
| | Thatâs also the arch for libgs.so, Iâll bet. | 23:07.27 |
| | so it works, then? | 23:07.41 |
| | might be good to try and repro on 4.2.2 | 23:08.08 |
| mvrhel_laptop | fredross-perry: yes | 23:12.45 |
| | fredross-perry: so your tiger is much different than mine. | 23:13.03 |
| | I will need to spend a little time making sure that mine (or yours) is correct doing a different color management path | 23:13.31 |
| Robin_Watts | mvrhel_laptop: Which 2 tigers are different? | 23:14.25 |
| mvrhel_laptop | Mine and fredross-perry's | 23:14.40 |
| | We are playing around with ICC profiles and gsproof | 23:15.10 |
| Robin_Watts | yes, but on what things? windows gsview vs linux gsview? | 23:15.22 |
| mvrhel_laptop | windows gsview on my side and I am guessing mac gsview on his end | 23:15.47 |
| | s/gsproof/gproof/ | 23:16.07 |
| | oh you are doing tiger.xps? how are you doing that | 23:19.47 |
| | I am running tiger.eps | 23:20.12 |
| | I can't do tiger.xps to gproof | 23:20.26 |
| | since I don't have gxps.exe available | 23:20.39 |
| | fredross-perry: ^^ | 23:20.49 |
| | not to mention I don't have a tiger.xps laying around and can't guarantee that it would be the same as yours. best to use the file in ghostpdl/examples/tiger.eps fredross-perry | 23:22.10 |
| | I am going to dig a bit into mupdf to see if I can figure out where things are going a miss in the listbox form object | 23:23.34 |
| Robin_Watts | mvrhel_laptop: Not all the form objects got implemented... | 23:24.19 |
| Robin_Watts | beds | 23:24.23 |
| mvrhel_laptop | well listbox was 1/2 implemented.... | 23:24.32 |
| | which is probably worst than not implemented | 23:24.50 |
| | the android app screws it up | 23:25.19 |
| | when you select the listbox, all the items from which you can select are null strings | 23:26.28 |
| | have a good night Robin_Watts | 23:27.20 |
| fredross-perry | doing tiger.eps, hang on ... | 23:31.46 |
| | Will mupdf open .eps directly? My gsview converts to pdf using gs, likee so: "gs" -P- -dSAFER -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile="/var/folders/cb/q4r8y5hn7y9498hrmx_p218r0000gr/T/gsview/tiger.eps.pdf" -c .setpdfwrite -f "/Users/fredross-perry/Desktop/tiger.eps" | 23:33.36 |
| rayjj | fredross-perry: mupdf doesn't understand PostScript (.ps .eps, ...) | 23:48.50 |
| fredross-perry | ok | 23:49.01 |
| | emailed you results from eps. | 23:49.08 |
| rayjj | so gsview converts it to PDF which mupdf can handle | 23:49.15 |
| fredross-perry | you=michael | 23:49.18 |
| rayjj | fredross-perry: me ? | 23:49.24 |
| fredross-perry | no, mv | 23:49.29 |
| | sorry | 23:49.34 |
| rayjj | fredross-perry: OK. I'd be happy to look at it as well, but I'm not sure what you need (I haven't perused the logs) | 23:50.20 |
| fredross-perry | Sorry, the question was for MV. He asked me to do a test that did NOT involve gxps. | 23:51.06 |
| rayjj | fredross-perry: pdfwrite converts to the "default" ProcessColorModel, which is *probably* RGB, so the CMYK that is in tiger.eps will have been converted (I think). You can look at the PDF to see if it has "# # # # k" or "# # # rg" (or K and RG operators). You will need to "mutool clean -d tiger.eps.pdf tiger.eps.d.pdf" to get "decoded" pdf | 23:55.30 |
| | if the tiger.eps.pdf has RGB color setting ops, the ghostscript will have converted the "setcmykcolor" from the eps to RGB (using it's color management) and the PDF won't show CMYK colorants. | 23:57.45 |
| | piano lessons (my son's) bbiaw | 23:58.20 |
| | Forward 1 day (to 2015/10/02)>>> | |
IRC Logs