| | <<<Back 1 day (to 2015/10/10) | 20151011 |
| tomty89 | hi some issue with the nimbus fonts. any idea why à èìòù with embedded nimbus fonts in pdf shows incorrectly? https://ptpb.pw/OGGn | 16:37.53 |
| | seems sans/mono/roman have problem but not sans narrow or other urw fonts | 16:39.28 |
| sebras | tomty89: the gs developers are usually not very active on sundays (not as much as during eu/us business hours during workdays at least). so you might need to hang around for some time to get an answer. | 16:41.43 |
| tomty89 | sebras: oh okay thanks :) | 16:42.34 |
| sebras | tomty89: just so you aren't surprised. :) | 16:42.39 |
| | tomty89: or, if you found a bug, file a bug report over at http://bugs.ghostscript.com/ | 16:43.51 |
| tomty89 | sebras: will do if i confirm | 16:45.18 |
| diemex | Hey, would it (theoretically) be possible to turn a pdf into android graphics objects to render from java? | 21:32.09 |
| sebras | diemex: the mupdf library can rasterise a pdf to an image. which I believe can be turned into a android graphics object. | 21:46.15 |
| printline | does anyone happen to know whether there is a mupdf based pdf viewer that supports text selection? | 21:46.49 |
| | mupdf-x11 does not seem to support that | 21:47.05 |
| sebras | diemex: whether there are suitable JNI-bindings for your usecase I don't know. I usually do not play around with android too much. | 21:47.09 |
| | printline: it does. use right-mouse button click and drag an area and it will be copied to your clipboard. | 21:47.46 |
| | diemex: the mupdf developers that know the JNI-bindings best are usually here during eu business hours during working days. I'm sure they will be able to help you. | 21:48.55 |
| printline | sebras: oh hey, thanks. that works very well | 21:50.56 |
| sebras | printline: I know. :) | 21:51.14 |
| printline | how come mupdf is so blazingly fast? or, how come the standard apps (Apple Preview.app, Adobe Readerâ¦) are so insanely slow? | 21:52.02 |
| sebras | printline: should you for som reason want to extract the text and process it, you can use mutool draw -F txt yourdocument.pdf and it will appear on stdout. | 21:53.17 |
| | printline: to be honest I have no real idea why they are so slow. personally I have been using mupdf as my go-to pdf-viewer the last 10+ years... | 21:54.31 |
| | printline: I think the main mupdf devs would be better equipped at answering _why_ it is fast, I'm just a contributor so I don't keep track of the general design ideas. :) | 21:56.53 |
| printline | sebras: I wished I had discovered it like 3 years ago, when I started loading heavy PDFs on a regular basis :D | 21:57.04 |
| sebras | printline: if you do come across documents which mupdf has a hard time to render quickly, but that other viewers render quickly. let us know about it, either here or over att http://bugs.ghostscript.com | 22:06.47 |
| printline | sebras: ok, Iâll report anything I find | 22:07.23 |
| | sebras: two last questions: can I jump to a particular page? and: can I read out which page is currently being shown, or output it upon quitting? | 22:08.02 |
| sebras | printline: yes, enter the page number using the numeric keys and then press g | 22:08.58 |
| printline | sweet, wasnât aware that this is also possible in vim, I always used : and then a line number | 22:10.33 |
| | hm, I could perhaps read the page from the window title | 22:11.02 |
| sebras | printline: that are more tips if you read the man page using "man mupdf" | 22:11.12 |
| printline | even marks, this is gold | 22:12.35 |
| sebras | printline: and you can go back using t. | 22:13.36 |
| | printline: there is also the undocumented feature of pressing upper case p to show the page number on top of the PDF, if you happen not to have a title bar (like me). | 22:14.15 |
| | agh! I mean "like I (do)" of course. :) | 22:14.50 |
| printline | nice, I have one, Iâm thinking about obtaining the page number there. I'd like to build a simple wrapper for mupdf-x11 that keeps track of the state (i.e. page number) of multiple documents that are loaded with it | 22:16.17 |
| | reading out the title bar is probably simpler than inspecting the process? | 22:16.51 |
| sebras | printline: aha. make sure to save the sha1sum of the file as well in case it changes. | 22:17.09 |
| printline | good point | 22:17.43 |
| sebras | printline: we do support reloading an opened file in case it is updated, e.g. if you generate a pdf using some makefile from e.g. a LaTeX source. (this can be triggered using r or SIGHUP) | 22:17.57 |
| | printline: I'm not sure which approach would be the easiest and most reliable to get the last page shown. | 22:18.42 |
| | printline: also, I should mention that a new open-gl-based viewer is in the works (but not yet finished I believe) so a few UI-things may change in the near future. | 22:19.37 |
| | printline: it is pretty late in my timezone so I need to leave. good luck with the wrapper script! :) | 22:21.52 |
| printline | perhaps I could change the code even? either as a new response to a different system call like SIGINFO or as a final output of the program? | 22:22.08 |
| | both? | 22:22.11 |
| | thanks for the info anyway | 22:23.17 |
| | Forward 1 day (to 2015/10/12)>>> | |
IRC Logs