| | <<<Back 1 day (to 2017/08/23) | 20170824 |
| aidos | I've just compiled the latest mupdf (been using a really old version) and it looks amazing. | 08:32.38 |
| | Main motivation was to try out the PDF to svg support. So far it looks really promising. I've read through the code and it looks fairly complete. Are there any known issues / missing features? | 08:34.00 |
| sebras | aidos: if you wait for tor8 to join the channel he might be able to tell you more about the svg support. | 08:35.25 |
| aidos | No problem. Thanks sebras. | 08:36.33 |
| tor8 | aidos: the svg output from mupdf is relatively complete. it doesn't cope with advanced transparency and blend modes, but all the basic stuff should work: vector art, text, images, shadings (flattened to images) | 10:43.32 |
| aidos | tor8: I've read through all the code now. It's very easy to follow. Without knowing a little more about the mutool rendering model, it's hard to totally understand how it's going to behave. I've been doing some experiments though. | 10:45.01 |
| tor8 | if you find any issues, please do report them and we'll try to fix | 10:45.35 |
| aidos | tor8: it looks as though a path that's filled and stroked will be added twice (one for each case), is that correct? | 10:45.35 |
| tor8 | that is correct | 10:45.41 |
| | that's how the internal graphics model does things | 10:45.51 |
| aidos | I figured that was the case. It's easy enough for me to rejoin those after the output is complete | 10:46.14 |
| | are they always done is the same order? | 10:46.28 |
| tor8 | if coming from PDF, then yes | 10:46.38 |
| aidos | fill then stroke for example or does it depend on how they're embedded in the stream? | 10:46.51 |
| | ok ok. Cool, that makes it even easier. | 10:47.02 |
| tor8 | fill first then stroke (so that the inside half of the stroke overlaps the fill) | 10:47.13 |
| aidos | Ah, of course. Makes sense. | 10:47.31 |
| | Another thing I saw in the code is the check that forces the stroke-width to a minimum of 1px | 10:47.49 |
| | That seems kind arbitrary, though maybe I'm missing something? | 10:48.07 |
| tor8 | aidos: PDF has the concept of 'hairline' width strokes--a zero (or near zero) linewidth is supposed to be one device pixel wide | 10:49.43 |
| | I reckon that's the purpose of that check. | 10:51.12 |
| | also PDF transforms the path *after* the stroking, where SVG transforms before (IIRC, it's been a while) so asymmetric scaling and shearing won't look 100% accurate in SVG | 10:51.57 |
| aidos | Ok. I'm familiar with them (ish). SVG actually has something similar (vector-effect="non-scaling-stroke") | 10:52.13 |
| | Oh really. I'll need to look into that more closely â in my mind SVG transforms after too | 10:54.10 |
| tor8 | it could be the code in svg | 10:55.01 |
| | -device is mistaken | 10:55.04 |
| | you'd have to ask Robin_Watts for the exact details around this, he wrote the larger part of the svg device | 10:55.27 |
| aidos | The other main question I have is around the groups. I see that they're implemented in the SVG device but I don't see them being called for any pdfs I've played with. | 10:55.34 |
| tor8 | the begin_group/end_group device calls are for PDF 1.4 transparency blend groups | 10:56.04 |
| aidos | Do you know under which circumstances begin_group and end.... | 10:56.10 |
| | Ah I see, so that's why they just do opacity. Gotcha | 10:57.01 |
| | And, the way the svg output device works is to effectively produce a "flat" svg which is more or less a list of paths with the appropriate properties. | 10:57.51 |
| | Is it possible to change the output device to maintain more of the original nested structure? | 10:58.33 |
| | (I understand that it would almost be a whole new device) | 10:58.47 |
| | More a theoretical question of whether there's enough info at this rendering stage to do that. | 10:59.22 |
| | So, for example, each new q context could be a new <g> tag etc | 10:59.44 |
| tor8 | aidos: there is no original nested structure in PDF | 10:59.51 |
| | you can squint a bit and pretend there is with the q/Q state saving | 11:00.16 |
| aidos | some pdf -> svg converters use the q/Q tags | 11:00.26 |
| tor8 | our pdf interpreter tracks the state but doesn't expose the bracketing to the final devices | 11:00.52 |
| aidos | does PDF dot apply the transforms in nested q tag? | 11:00.54 |
| tor8 | they just get the final transform matrices and other graphics state | 11:01.22 |
| | clip_xxx/pop_clip is the only real bracketing you can spot with our device API | 11:01.40 |
| aidos | Right, I figured that might be the case. | 11:01.51 |
| | I was wondering if I could somehow extract "layer" information | 11:02.29 |
| tor8 | if you're willing to do a bit more work, you can write a 'pdf processor' bit of code | 11:02.32 |
| aidos | I have some PDFs with things like `/OC /MC0 BDC` | 11:03.17 |
| tor8 | in mupdf we have a 'pdf processor' layer that sits between the interpreter and the device. the default implementation is what calls the devices for drawing or outputting other formats | 11:03.31 |
| aidos | which you could use as sort of nested context | 11:03.36 |
| | ah ok | 11:03.43 |
| kens | That's optional content, not nested content | 11:03.48 |
| tor8 | we have two other implementations, one that does syntactic cleanup (mutool clean with the - | 11:03.48 |
| | -s flag) | 11:03.51 |
| aidos | Used that for the first time today! | 11:04.16 |
| tor8 | the pdf processor API gets all the raw graphics calls from the PDF content stream as function calls | 11:04.30 |
| | so there's a call for each operator (q, Q, cm, l, f, etc) | 11:04.45 |
| | you could write one that translates to svg from that sequence of calls | 11:05.00 |
| | of course, you then lose the ability to convert from anything other than PDF | 11:05.27 |
| aidos | (which in my case, I'm ok with) | 11:05.39 |
| | So, more generally â is there a good place to start to understand the general model of the library? Does mutool use any ghostscript code at all? | 11:06.34 |
| | It seems like mutool kinda does, parse document into internal structure -> write onto output device | 11:07.07 |
| | I'm sure it's more complicated than that, but at the highest level, is that the behaviour? | 11:07.29 |
| tor8 | there's not much code from ghostscript in mupdf. a few bits owe their lineage to some gs code (image decompression filters) and the I originally wrote the XPS parser for GS and then ported it to mupdf | 11:07.43 |
| aidos | ok cool. However it works, it's fast and in my experiments, much more accurate than anything else | 11:08.41 |
| | :-) | 11:08.44 |
| tor8 | aidos: in the windows release there's a prerelease of a book that Robin_Watts wrote detailing the source: MuPDF Explored | 11:08.47 |
| | https://ghostscript.com/~robin/mupdf_explored.html has a web version of that you can browse | 11:08.59 |
| aidos | Oh brilliant. That looks like a great place to start. | 11:10.49 |
| tor8 | https://mupdf.com/docs/ (same content as in the source checkout docs/ directory) | 11:11.51 |
| | has some very high level and introductory docs (more how to use than how to hack on) | 11:12.10 |
| | the header files in the source also have a fair amount of documentation about each function | 11:12.23 |
| aidos | I guess I'll have a dig around in the syntactic cleanup code to get an idea of how / what can be done at the processor level | 11:12.32 |
| | really appreciate all the info | 11:13.22 |
| | we've used a bunch of different product for pdf->svg conversion | 11:13.44 |
| tor8 | aidos: if you're familiar with PDF syntax, you could start by copying source/pdf/pdf-op-buffer.c and hooking that up to a new tool you write | 11:13.47 |
| aidos | inkscape, cairo, pdftron and pdffly (opensource and commercial) | 11:14.23 |
| tor8 | that's the no-op pdf processor that just prints back out the input | 11:14.24 |
| aidos | as time has gone on, we've found that bugs in commercial products eat a lot of our time and our default process for a bad document now is to expand it out with mutool and then hand edit | 11:15.30 |
| | I'm really rather excited to find that you know have an svg converter, and so far it looks really promising | 11:16.01 |
| | more than anything, the code I've looked so far has been really easy to follow (and it's really fast compared to most other solutions) | 11:16.59 |
| | I'll read through the docs and start having a look at the processors to get a better idea of the model | 11:17.26 |
| tor8 | I try to write simple code, otherwise I can't remember how it works when I come back to fix bugs in it later :) | 11:17.34 |
| aidos | haha, tell me about it | 11:17.43 |
| | tor8: thanks again for you help today. I'll probably be back again with more questions ð | 11:18.31 |
| tor8 | np. | 11:18.37 |
| | it's going to be a rather big task though, you'll need to track and keep track of a fair amount of obscure PDF graphics state and replicate the text and font encoding/layout logic of PDF | 11:20.20 |
| aidos | tor8: I'm sure you're right, and I'm sure it's more trouble than it's worth. I'm just looking at hypotheticals to try to better understand what the options are. Reading through pdf-op-filter.c it all looks fairly approachable. It might even be that I could hack around with that a little if we need to customise the process. | 11:35.28 |
| sebras | Robin_Watts: FITZ_DEBUG_LOCKING makes no sense to me. | 15:44.12 |
| | Robin_Watts: fz_lock() calls fz_lock_debug_lock() which checks its states before ctx->locks->lock() is called. but the lock might be taken at that point and the thread would need to block for some time until the other thread has released the lock. | 15:45.10 |
| | wouldn't fz_lock_debug_lock() just print an error message in this case and after that we'd wait for the other thread to release the lock? | 15:46.21 |
| Ramez | Good morning everyone. We are looking for help with MuPDF on Android. We are facing this challenge: How do we control position and sizing of MuPDF (we are using MuPDFActivity). If it's complicated we can hire expert(s) to help us with this. | 15:47.09 |
| sebras | Robin_Watts: we have rarely seen this before because bgprint_worker() didn't take the lock for extended periods of time, but since I make ft_alloc() chain into fz_malloc_no_throw() this happens more often. | 15:47.14 |
| | Robin_Watts: hence we get these error messages even for the simple ./build/memento/mutool draw -st -o /tmp/test%02d.png -F png -P testdocument.pdf 1,2,3 | 15:47.42 |
| Ramez | Thanks so much! Look forward to being part of this active community. | 15:47.44 |
| sebras | Ramez: hi! so you mean you don't want the gestures on the screen to control what part of the pdf is shown, but you want to do this programatically? | 15:49.10 |
| | Ramez: most of the mupdf developers are online during european business hours mon->fri (i.e. the just left), myself I'm in asia at the moment and should really be sleeping now. :) | 15:50.23 |
| Ramez | @sebras: Thanks for the response. I am ok with gesures controlling location, I want to size the container window / frame to only show PDF in a specific location / dimension | 15:50.38 |
| sebras | Ramez: yes the current apps fill the screen. I haven't worked with views where the root view doesn't fill the entire screen, but I believe android supports that somehow. | 15:52.29 |
| | Ramez: what kind of app are you developing? | 15:53.19 |
| | Ramez: sounds like you'd want the rest of the screen to show something other than the pdf document..? | 15:53.34 |
| Ramez | @sebras: Yes it's an educational app, we need to control the screen to take students out to another learning resource | 15:54.09 |
| | @sebras: so need tight control (there is a navigation bar for the app at the top) | 15:54.27 |
| | Thanks @sebras, I'll connect later then. Appreciate the courtesy. Sleep well | 15:57.12 |
| sebras | Ramez: aha, I see. so the company you are working for will then sell content in this app? | 15:58.23 |
| | Ramez: at this point I should remind you that MuPDF is available under the AGPL license. this means that you must be able to give away the source code to your entire application, licensed under AGPL (or compatible license). | 15:59.29 |
| | Ramez: you need to real the AGPL license terms for details of course. | 15:59.50 |
| kens | You can also seek a commercial licence | 16:00.01 |
| sebras | Ramez: if you cannot or do not want to give away the entire source code to your app you can also contact sales@artifex.com and negotiatiate a commercial license. | 16:00.27 |
| | Ramez: this means that you cannot simply integrate MuPDF into your app without considering the license and what you are prepared to do with the source code of your app. | 16:01.23 |
| | Ramez: it would be bad if you wasted time on integrating MuPDF only to later find out that you cannot abide by the license terms and at this point start negoriations for a commercial license. better to do it early. :) | 16:04.52 |
| Ramez | Ouch - thanks for the notice. You're right | 16:08.54 |
| sebras | Ramez: with a commercial license you may also get support, depending on the negotiations with sales@artifex.com | 16:12.52 |
| | Forward 1 day (to 2017/08/25)>>> | |
Log of #mupdf at irc.freenode.net.