| | <<<Back 1 day (to 2017/12/10) | 20171211 |
| Robin_Watts | sebras: Probably we should remove those lines, and replace them with a comment saying "We used to test for overrun here, but now don't because...." | 00:28.19 |
| sebras | Robin_Watts: I'm looking into the latest security bug. | 00:59.28 |
| Arno | I just want to say thank you to implement page fit to mupdf mini. | 11:25.43 |
| | :) | 11:25.46 |
| tor8 | Arno: you're welcome! | 11:26.18 |
| Arno | May I suggest you to add another cool feature. While reading pdf if happens, that the border around the actual text is quit big. That means, I lose resolution because I see the white space around the text too. | 11:27.20 |
| | It would be great to have a zoom, which can be locked. So that I can see next (as for instance in page fit mode) the next page with same zoom and same positioning. | 11:28.21 |
| | Or: in case of width-fit, scroll trough the page without a the zoomed area is moved to left of right. | 11:29.11 |
| | Can you understand the idea? My english is far away from perfect ;) | 11:29.31 |
| tor8 | Arno: I understand your idea. | 11:30.42 |
| | I also dislike it ... I am the opposite -- I want proper margins and really dislike it when documents have text right up against the border. | 11:30.48 |
| | detecting the actual margins used by a page is non-trivial | 11:31.39 |
| | if you zoom in, the zoom level should be kept between pages as it is | 11:32.07 |
| | but we don't automatically compensate for margins | 11:32.20 |
| Arno | I guess margin detection is difficult. Also fixed zoom is not perfect, as margin might change from page to page. So even page is different to odd. | 11:33.18 |
| tor8 | if we could trivially find the margins, adjusting the smart scrolling to ignore them would be doable | 11:33.34 |
| Arno | But I can gain a little more resolution ;) | 11:33.37 |
| tor8 | Arno: "mupdf viewer" does high resolution zooming, so that may work for you too | 11:34.38 |
| Arno | Automatic detection migh be misleading due to headers and feeters, that might be not of interest. So as for instance in a newspaper. | 11:34.38 |
| tor8 | adding high res zooming to mupdf mini is on my TODO list | 11:34.51 |
| Arno | Another thing I often need is to switch between latest few (I most read two) documents. I handle that by using mupdf mini and mupdf viewer. So I can switch with :) | 11:37.35 |
| tor8 | Arno: you can open several documents at the same time with just mupdf mini | 11:37.55 |
| | just use the square "activity chooser" button and pick the file chooser and you can open another document | 11:38.18 |
| | don't use the 'back' button | 11:38.28 |
| Arno | What do you mean with activity chooser. The lower bar in Android where you see history of apps? | 11:39.10 |
| tor8 | the lower system bar in Android where you have the back and home buttons | 11:39.49 |
| | the third one, which is a square on some phones, is the "overview" that shows all open apps | 11:40.10 |
| | if you use that button to go back to the mupdf mini file chooser, you can open multiple documents | 11:40.39 |
| Arno | With this I switch between the both mupdf readers. Can I also switch to different documents opened with same reader? I doubt this can work.... | 11:41.07 |
| tor8 | Try it. It works on every device I have tested it on. | 11:41.36 |
| Arno | cool! | 11:41.47 |
| | Back to the margin stuff. Do you like the idea to lock the zoom and position. So in case of page fit the position of the upper right and lower left position. In case of width-fit just the left and right positions of the document? | 11:43.25 |
| sebras | tor8: how much ram do you have in your machine? | 11:43.35 |
| Arno | There is one reader out that can handle that - but it has other deficts. So I like yours much more! | 11:43.54 |
| tor8 | sebras: which machine? | 11:43.58 |
| Arno | Just 2G, rather poor for a HiRes 10" display | 11:44.19 |
| sebras | tor8: your development machine. | 11:44.20 |
| | tor8: I have a murun .js-file which attempts to add 100 million objects to a PDF document and it sometimes completes and sometimes fails (out of memory). | 11:44.41 |
| Arno | sorry ! I should shut up | 11:44.44 |
| tor8 | sebras: 16GB | 11:44.48 |
| sebras | tor8: then you are in a better position to test this one than I am. | 11:45.10 |
| tor8 | 100 million objects is rather a lot | 11:45.24 |
| sebras | tor8: 4Gbyte had errors so I threw them out. | 11:45.25 |
| | tor8: it is, but it only took me 2 minutes when it worked. | 11:45.34 |
| | tor8: and we wrote a bogus .pdf | 11:45.41 |
| tor8 | what happens if you manually trigger a gc() call every 100k objects or so? | 11:45.43 |
| sebras | tor8: I didn't try that. | 11:46.18 |
| tor8 | it might still run out of memory | 11:46.50 |
| | the gc should be auto | 11:47.00 |
| | triggered every N allocations though | 11:47.06 |
| sebras | tor8: I think the problem is that the PDF itself is rather large. | 11:47.12 |
| | tor8: it is 4811797021 when done. and so we write negative offsets into the xref. | 11:47.31 |
| tor8 | yes. I would not be surprised if there are some 32-bit integers around in the pdf writing code. | 11:47.54 |
| sebras | tor8: actually all objects are ints | 11:48.11 |
| | tor8: object numbers that is. | 11:48.22 |
| | tor8: I'm experimenting with making them int64_t | 11:48.32 |
| tor8 | that shouldn't matter to the xref writing code | 11:48.33 |
| | pdf_obj numbers are either double or int64_t | 11:48.42 |
| | ah, object *numbers* | 11:49.09 |
| sebras | yes. | 11:49.15 |
| tor8 | do we have more than 2G objects? | 11:49.20 |
| sebras | tor8: no, but the file offsets are > 2GByte. | 11:49.50 |
| | tor8: that part I could fix by simply doing %u instead of %d. | 11:50.09 |
| tor8 | I'd throw an exception there if we try to create an indirect reference/object with a number > 2G | 11:50.30 |
| | file offsets should all be 64-bit! | 11:50.47 |
| | that's what the whole fz_off thing was about | 11:50.56 |
| | if there are any file offsets left in the code that are not int64_t then they are bugs | 11:51.26 |
| sebras | tor8: cool, then I'll fix those. | 11:51.37 |
| tor8 | thanks. | 11:51.49 |
| sebras | pdfref17 mentions object numbers being < ~8M | 11:51.58 |
| tor8 | now I'm trying to figure out why dead keys don't work with freeglut on windows :( | 11:52.08 |
| sebras | just opened pdfref20 | 11:52.10 |
| tor8 | where does it say? | 11:53.17 |
| sebras | page 992 | 11:53.41 |
| | "indirect object" --> limit = 8388607 | 11:53.50 |
| tor8 | ah, found it! | 11:53.53 |
| | pdfref20 removes the specific limits | 11:55.22 |
| sebras | yes, I just finished reading annex c | 11:55.42 |
| tor8 | because the pdfref17 only gives the table saying what Adobe's limits are | 11:55.43 |
| sebras | right. | 11:55.49 |
| tor8 | not saying they're limits of the actual spec | 11:55.53 |
| | but I reckon hard coding an error for exceeding the limits given in pdfref17 would be good enough | 11:56.13 |
| sebras | and pdfref20 also mentions, as I figured out yesterday, that object streams would be able to compress objects a lot and squeeze more objects into a 10 GByte PDF. | 11:56.23 |
| tor8 | we don't want to create files that adobe can't open anyway! | 11:56.23 |
| | yes. compressed object streams can do that... but they mean having to decompress the whole stream into memory just to read one object in the middle. | 11:57.03 |
| sebras | tor8: in that case it is sufficient to have offsets be int64_t and object numbers be int (since it is less than 8388607 on any platform we care about). | 11:57.17 |
| | larger, not less. :-P | 11:57.25 |
| tor8 | yes. object numbers should stay as int. | 11:57.26 |
| | file offsets should be int64 | 11:57.41 |
| | if you have more objects than fit in a 32-bit signed integer, you're asking for trouble | 11:57.59 |
| sebras | tor8: this is exactly what I was asking for yesterday. | 11:58.15 |
| | tor8: and I got it, the linux OOM-killer didn't want to kill my gdb session that was trying to eat up all memory. then everything became _very_ slow. after 30 min I managed to ctrl-c q y enter to get it killed. | 11:59.07 |
| | tor8: that doesn't happen when I run it on the command line though. in that case realloc() failed when trying to allocate > 4Gbyte. | 11:59.47 |
| | tor8: one more thing about these offsets though. | 12:40.19 |
| | tor8: when things are linearized there is a linearization dict at the beginning of the file that hold the file length and offsets to the first page and other things. | 12:40.58 |
| | tor8: since these are numbers in a dict, they cannot represent all the bytes in a full PDF file, since 9999999999 < 2**31 | 12:41.41 |
| tor8 | sebras: numbers are 64-bit doubles or int64_t | 12:42.12 |
| | pdf_new_int takes an int64_t | 12:42.24 |
| | just for this reason | 12:42.31 |
| sebras | tor8: ah, now I see it, we have pdf_to_int() return int | 12:46.58 |
| | and pdf_to_int64() return int64_t. | 12:47.04 |
| | but the latter is not called where it should. | 12:47.12 |
| | e.g. in pdf_load_linear. | 12:47.21 |
| baimafeima | morning | 14:30.52 |
| | can you guys add screenshots to your website of how mupdf looks like when running on linux-based OS? | 14:31.06 |
| sebras | baimafeima: seems like some linux mint people did a screenshot a while back https://community.linuxmint.com/img/screenshots/mupdf.png | 14:32.39 |
| baimafeima | sebras, thanks, would be great if you guys could add some up to date ones on your site though | 14:33.32 |
| kens | There would be confusion. | 14:33.55 |
| | MuPDF is really a cross platofrm library | 14:34.11 |
| | Each of the viewers is a sample application | 14:34.21 |
| | And tehy all differe in appearance and capabilities | 14:34.30 |
| | So choosing any one woudl be confusing. And doesn't represent 'MuPDF' really, it just represents a particular viewer | 14:34.54 |
| | Also, which website ? :-) | 14:35.03 |
| sebras | kens: my thought exactly. :) | 14:35.14 |
| kens | sebras, but your thoughts probably ommitted the typos.... | 14:35.45 |
| sebras | baimafeima: are you apprenhensive about installing it and try it out? | 14:35.57 |
| | kens: no, I meant about the website. | 14:36.10 |
| kens | ah.... | 14:36.16 |
| sebras | kens: there were no typos in that sentence. congrats! :) | 14:36.27 |
| baimafeima | the mupdf.com site | 14:36.42 |
| kens | I can manage short sentences, one day I hope to be able to type medium length sentences | 14:36.54 |
| sebras | baimafeima: seems like debian used 1.9 to do a screenshot rather than 1.9 https://screenshots.debian.net/package/mupdf | 14:41.04 |
| | baimafeima: these all seem to be the mupdf-x11 viewer. | 14:41.21 |
| | baimafeima: the mupdf-gl viewer can e.g. display the document outline while mupdf-x11 cannot. | 14:41.38 |
| | baimafeima: the mupdf android viewer apps also displays the document outline but differently from mupdf-gl. | 14:42.14 |
| | baimafeima: lastly you have the ones on the app stores: https://itunes.apple.com/us/app/mupdf/id482941798?mt=8 https://play.google.com/store/apps/details?id=com.artifex.mupdfdemo https://play.google.com/store/apps/details?id=com.artifex.mupdf.viewer.app https://play.google.com/store/apps/details?id=com.artifex.mupdf.mini.app | 14:43.41 |
| baimafeima | sebras, thanks | 14:58.51 |
| sebras | tor8: a sequence of commits on sebras/master, the first one adresses two of the three open security bugs. (the third bug doesn't yet have a pdf file with which to reproduce the issue). | 23:42.04 |
| | tor8: I also corrected the int64_t usage in pdf-xref.c for the fields that were named ofs, but wasn't file offsets (but rather xref subsection object number offsets) | 23:43.05 |
| | Robin_Watts_: if you have time to take a look, feel free to do so. :) | 23:43.46 |
| | Forward 1 day (to 2017/12/12)>>> | |
Log of #mupdf at irc.freenode.net.
