| | <<<Back 1 day (to 2011/10/14) | 2011/10/15 |
| LaoLang_cool | hi! | 03:06.58 |
| | a advice for mupdf, j/k/h/l should move by line, not by lines, J/K/H/L then could move by lines | 03:07.41 |
| mvrhel2 | ok. dot shape can now be set/specified in the ordered dithered threshold array creation tool | 06:05.37 |
| | now to add in different vertical and horizontal resolution | 06:05.49 |
| Robin_Watts | has new RAM to fit. This could be fun... | 10:26.05 |
| sebras | LaoLang_cool: hjkl moves by 1/10th of the height/width. nothing is known about font size (and thus line height) in the viewer. | 12:14.55 |
| LaoLang_cool | sebras: got it, thx | 12:34.12 |
| | 1/10th is a little big.. | 12:34.32 |
| | What about 1/20th.. | 12:34.41 |
| sebras | LaoLang_cool: I don't think tor8 has an opinion on the exact fraction, but in case you can not wait then you can change the fraction on your own in apps/pdfapp.c::pdfapp_onkey(). Look for the comment "Pan view, but dont need to repaint image" and you'll be in the right area. | 14:19.39 |
| LaoLang_cool | sebras: thanks! I don't want to compile the pkg by myself ;p it's a personal taste, maybe tor8 is comforted with the current setting, I can get used to it ;p | 14:23.52 |
| arthurf | While researching 692591, I used pdfshow with grepable to examine the PDF objects, and it tripped over object 1751 because of the enormous string size. | 14:45.20 |
| | To get around that, I changed the size of the scratch character array in pdf_xref_s within pdf_xref_s from 65536 to a higher value. | 14:46.57 |
| | oops - within mupdf.h - it's still early | 14:47.17 |
| | anyway - does tor8 or Robin_Watts (when online) have a suggestion about how much the size of the scratch char array could be safely increased to? I can write up the bug after I review the logs later. | 14:50.18 |
| sebras | arthurf: that string is >300kbyte unparsed and >120k parsed. according to pdfref17 there is a limit of 32kbyte for strings. according to the note it only applies to strings in content streams, and this one is just stored in a dict in object 1751. | 15:37.39 |
| | arthurf: so it seems as if the pdf itself is not invalid at least. but having such long strings is rare indeed. :) | 15:38.44 |
| arthurf | sebras: Thanks. I should have asked the three of you about an alternative value for the scratch character array - I recalled reading in one of the logs (of course after having entered my messages) that tor8, sebras and Robin_Watts have deep knowledge of mupdf and friends. | 16:16.07 |
| | sebras: The value that I used was 131072 (65536 * 2). But I am aware of the Android development going on - and wasn't sure if that suggested value was too high for some reason. | 16:16.56 |
| Robin_Watts | arthurf: My machine is not in a state to go looking at the moment, but I have no knowledge of that item. | 16:18.13 |
| | I suspect we should be redoing that bit of the code. | 16:18.56 |
| | (possibly as part of the 'no globals' push) | 16:19.05 |
| arthurf | Robin_Watts: Exactly, I read that you and tor8 were overhauling the code as well - so that was another reason to hold on opening a defect on this setting - perhaps better to just talk about it. | 16:22.00 |
| Robin_Watts | SSD and Windows 7 ordered. | 16:45.56 |
| | 8Gig of RAM in, and running (and passes MemTest86 4 with all it's funky multicore magic) | 16:46.20 |
| sebras | Robin_Watts: congrats! :) | 21:14.52 |
| a271828 | Hi -- I have a question to mupdf developers. | 22:28.15 |
| | First of all -- great idea to have vi-keys. However I am missing some important features -- how to get to "2 pages view" ? | 22:29.21 |
| sebras | a271828: that is currently not implemented in the viewer. | 22:47.06 |
| | a271828: when the new viewer is implemented continuous view and facing view will definitely be looked at. | 22:47.52 |
| | a271828: if you are on windows, you may want to take a look at SumatraPDF which uses mupdf for rendering PDF-files, but has its own GUI on top. | 22:48.33 |
| | Forward 1 day (to 2011/10/16)>>> | |
IRC Logs