| | <<<Back 1 day (to 2018/02/14) | 20180215 |
| sebras | tor8: "Accept NULL in fz_drop_output." LGTM | 11:09.34 |
| | tor8: concerning "Use proper encoding for pdf_field_value and update_field_value." I'm worried about the V entry in the group dictionary that you add in toggle_check_box(). on page 686-687 in pdfref17 it seens this should be a name, not a text string..? | 11:15.08 |
| | the same also makes me wonder about whether using a text string is correct in update_field_value(). | 11:17.20 |
| | I can see that both address the encoding which the previous code did not take into account though. | 11:18.05 |
| tor8 | sebras: page 676 says V is of type (various) | 11:21.02 |
| sebras | yeah, it depends on the field. | 11:21.13 |
| | so for check boxes it is a name | 11:21.22 |
| | for other fields it might be something else (I haven't checked) | 11:21.31 |
| tor8 | and on page 695 for choice widgets it says 'text string' | 11:21.43 |
| | ah, wrong commit | 11:22.03 |
| | there's another one for check boxes in the earlier commit | 11:23.02 |
| | yeah, that just keeps the original mistake :( | 11:23.07 |
| sebras | yes, perhaps we can fix it at a later time at least. :) | 11:23.44 |
| tor8 | sebras: yeah... | 11:24.09 |
| sebras | your patch intended to fix the encoding, and it does. | 11:24.38 |
| | tor8: in "Use text encoding for pdf_choice_widget options and values." | 11:27.37 |
| | I notice that vals might have a length of MAX(nvals,nopts) but when you free it in fz_always() you only free nvals elements. | 11:28.14 |
| | that MAX() looks a bit bogus to me. why is it there? | 11:28.31 |
| | tor8: "Don't use constants larger than will fit in a signed int in enum." maybe we can mask out the reserved bits among the pdf permissions but have them be or:ed in when setting the permissions, that way you wouldn't have to set all reserved bits to 1, avoiding the issue with signed/unsigned..? | 11:31.37 |
| | so we return the permission bits themselves, but not the reserved bits (would the caller even care about them?). | 11:32.08 |
| tor8 | sebras: better ask paul about the MAX | 11:44.26 |
| | I just made sure to free what was actually allocated | 11:44.40 |
| | which is nvals | 11:44.52 |
| | maybe winchoiceinput uses it? | 11:46.12 |
| sebras | paulgardiner: why is there a MAX(nvalx, nopts) for PDF_WIDGET_TYPE_COMBOBOX/LISTBOX in pdfapp_onmouse() in platform/x11/pdfapp.c? | 12:02.57 |
| | wouldn't just nvals be enough? | 12:03.07 |
| paulgardiner | sebras: hang on. I'll take a look in a mo | 12:03.32 |
| | I think that may be necessary. I'm not sure what winchoiceinput currently does, but it could allow all the opts to be selected, which would require vals to accommodate at least nopts values. | 12:11.39 |
| | using nopts to allocate vals might be okay, but a corrupt file may have more options selected than there are options - if you see what I mean. | 12:12.33 |
| sebras | paulgardiner: ok, but then when freeing it, we should also be freeing MAX(nvals, nopts) I believe, which necessitates a change in tor8's commit. | 12:13.23 |
| paulgardiner | That sounds correct. | 12:13.42 |
| | Ah no. I think there will always be nvals values in vals. | 12:16.19 |
| | winchoiceinput will update nvals. Hmmm, it probably doesn't free ones it drops at the moment. | 12:17.03 |
| | I'm confused. | 12:17.17 |
| | Implementations of winchoiceinput might be copying pointers to strings from opts to vals, If so, that needs changing too, I think. | 12:19.01 |
| | I'd sort of like it to work via indexes into opts, but that's not how the info is held in the file, IIRC. | 12:22.54 |
| NilsonT | Hi there, it is possible to change annotation icon from library MuPdf? | 13:32.55 |
| kens | NilsonT I don't undertand what you mean. What annotation icon ? | 13:49.13 |
| NilsonT | that is, when you create an annotation in a book, I have currently worked on creating it and what I have been able to do with the C library, is change the color, the function is called pdf_update_text_annot_appearance. I explain? | 13:51.59 |
| kens | What kind of annotation are you taling about ? A Highglight ? FreeText ? Stamp ? something else ? | 13:52.34 |
| | Perhaps you could put an example somewhere that we could look at. Its easier to discuss a concrette example. | 13:53.11 |
| NilsonT | the type of annotation is free text | 13:54.47 |
| kens | OK.... | 13:55.20 |
| | So FreeText annotaiotns don't have an icon | 13:56.03 |
| | They display text directly onto the rndered PDF page | 13:56.12 |
| | So I'm puzzled by what icon you mean | 13:56.30 |
| NilsonT | no, one sec, I'm uploading class to show you | 13:56.53 |
| | https://github.com/NilsonT/MuPdf-annotations | 14:05.34 |
| kens | Sorry, I can't help you with code, I'm not one fo the MuPDF developers. | 14:06.19 |
| | tor8 paulgardiner ^^ | 14:06.54 |
| NilsonT | OK, who can help me? you could tell me? | 14:07.00 |
| kens | One of the people I just pinged probably | 14:07.15 |
| NilsonT | Alright, thanks a lot | 14:09.27 |
| kens | NP stick around until one of them replies, or come back later and check the logs | 14:09.45 |
| NilsonT | OK | 14:10.31 |
| paulgardiner | tor8: you mentioned load_droid_fallback_font. I may be misunderstanding it, but that doesn't look like it's part of the mechanism for loading the base fonts (base could be the wrong word - I know little about fonts) | 15:27.14 |
| tor8 | paulgardiner: the base14 fonts for PDF are hardwired in (because we really need them to be there) | 15:28.35 |
| paulgardiner | Ah okay. | 15:28.51 |
| tor8 | the fallback font mechanisms we have are for non-base14 fonts, such as those used to substitute missing fonts | 15:28.58 |
| | fz_install_load_system_font_funcs is the entry point for all this | 15:29.10 |
| paulgardiner | Okay, so potentially there could be just a few very big fonts that would do for fallback? | 15:29.37 |
| tor8 | that takes three callbacks, one for regular system fonts, one for cjk system fonts, and one for a last ditch give me a font that can do this unicode script | 15:29.42 |
| | the idea is that if a PDF file does not embed a font, the first of these hooks will let the client look through the system fonts for one with a matching name | 15:30.13 |
| | if it finds one, it will return it, otherwise mupdf will fall back to using a base14 font as a substitute | 15:30.30 |
| | similarly for CJK fonts | 15:30.35 |
| | the third callback is for EPUB, when the font we have doesn't have the character set we need it will ask for a font which covers the requested character set | 15:31.14 |
| | if you don't care about EPUB, you can just ignore that one and build with TOFU | 15:31.37 |
| paulgardiner | So is it just this one callback that PDF needs? | 15:31.38 |
| tor8 | and PDF doesn't *need* it -- we provide it should clients want to dig for system fonts if the fonts are not embedded | 15:32.08 |
| | the default behavior is to *not* look for system fonts | 15:32.16 |
| | but sumatrapdf used to use this mechanism (but they forked mupdf a couple of years ago, so who knows what they're doing today) | 15:32.44 |
| | now, if you want EPUB support, you should ideally implement the load_fallback_font callback to find a proper system font | 15:33.13 |
| | otherwise we will only be able to display latin scripts | 15:33.21 |
| | (assuming you build with TOFU to reduce the binary footprint) | 15:33.40 |
| paulgardiner | Yes, so I do need it to keep some sort of parity with non-TOFU builds. | 15:34.11 |
| tor8 | paulgardiner: yes. but only SVG and EPUB use the 'load_fallback_font' fonts. | 15:39.29 |
| paulgardiner | Losing me here. Is that load_fallback_font, as opposed to load_droid_fallback_font? | 15:41.47 |
| tor8 | load_droid_fallback_font is the android specific callback that implements the load_fallback_font interface | 15:42.22 |
| paulgardiner | Which I don't need for PDF documents? | 15:42.56 |
| tor8 | you don't need ANY of the callbacks for PDF documents to match the default behavior (regardless of TOFU build or not--pdf doesn't use the Noto fonts) | 15:43.32 |
| | you can use the two first callbacks for PDF documents if you want to use system fonts to substitute missing fonts that aren't embedded | 15:44.12 |
| | you need the third callback for SVG and EPUB documents. | 15:44.23 |
| paulgardiner | So TOFU will make no difference to PDFs? | 15:45.08 |
| tor8 | paulgardiner: pdf_load_font_descriptor calls either pdf_load_builtin_font (for the base14) or pdf_load_system_font (for non-base14 fonts) whenever it needs a font that is not embedded | 15:45.35 |
| | correct, TOFU has no effect on PDF | 15:45.42 |
| | it only affects EPUB | 15:45.46 |
| | (unless you do TOFU_CJK or TOFU_BASE14) | 15:46.03 |
| | EPUB calls fz_encode_glyph_with_fallback | 15:46.22 |
| | if you start digging from those three functions you should get an overview of what needs what. those three functions are the start points for all font loading. | 15:46.46 |
| paulgardiner | I'd rather just ask. | 15:47.29 |
| tor8 | paulgardiner: what if I pretend to be busy next time? ;) | 15:48.08 |
| paulgardiner | I'll cry | 15:48.22 |
| | tor8: is there a distinction here between the tofu make target and the TOFU C flag? The tofu target defines CMAP_GEN= and XCFLAGS="-DNOCJK". I would have imagined that that would affect PDF. | 16:03.37 |
| tor8 | paulgardiner: yes. there's a plethora of configuration options here. | 16:07.06 |
| | for your use, I recommend setting -DTOFU (or just read the top of source/fitz/noto.c and decide from there) | 16:07.27 |
| | the 'make tofu' target is for small platforms where building the generated files is difficult | 16:07.49 |
| paulgardiner | For the tofu target, is there an existing mechanism for using system versions of the base fonts, cjk fonts and cmaps? | 16:08.45 |
| tor8 | if you implement the load_system_cjk_font callback, you can use -DTOFU -DTOFU_CJK to build with only the required CMaps and base14 fonts (and need a CJK system font for displaying actual CJK text) | 16:09.06 |
| | if you do not implement any callbacks, use -DTOFU -DTOFU_CJK_EXT to get the base14 fonts and the smallest CJK font | 16:09.33 |
| | there is no provision for using system versions of the base fonts and cmaps | 16:09.57 |
| | the base fonts are not even available on android phones. | 16:10.30 |
| | at least I haven't seen Helvetica on the phones I've looked at | 16:10.53 |
| | and even if there was a font named Helvetica, it probably wouldn't have matching metrics | 16:11.57 |
| malc_ | tor8: i guess it's pretty safe bet that arial or roboto will be there | 16:12.00 |
| tor8 | malc_: yeah, but not good enough. we need fonts with the exact metrics or layout will be wonky. | 16:12.18 |
| malc_ | tor8: i actually bought helvetica from linotype some years backs.. and it doesn't have the exact metrics | 16:13.10 |
| tor8 | malc_: which is why we embed it and always use our own... | 16:13.29 |
| | which we know matches metrics with adobe's | 16:13.41 |
| malc_ | tor8: our own urw knock off :) | 16:13.47 |
| tor8 | but of course :) | 16:13.59 |
| malc_ | tor8: have you ever seen adobe's helvetica? does acrobat ship with it? | 16:15.02 |
| paulgardiner | Even if not present as system fonts, we may need to support supplying them separately to the binary to avoid their being present four times in the SDK | 16:15.58 |
| tor8 | paulgardiner: see fz_lookup_builtin_font | 16:17.23 |
| | that is what you need to replace | 16:17.35 |
| malc_ | https://spiekermann.com/en/helvetica-sucks/ | 16:19.51 |
| tor8 | paulgardiner: the base 14 fonts are in CFF format, and they NEED to be in CFF (or type1) format | 16:20.19 |
| | truetype will NOT work for pdf. | 16:20.24 |
| | truetype fonts behave differently in PDF, so will not work as substitutes | 16:20.35 |
| malc_ | tor8: what's the difference? | 16:21.17 |
| tor8 | how PDF handles encodings | 16:21.32 |
| | anyway, I need to pop out for a few hours | 16:21.52 |
| | pdf_load_simple_font_by_name has a lot of logic that switches depending on whether the font is TTF or Type1 (so as to behave accordingly with the PDF specification) | 16:22.39 |
| | the base 14 fonts need to be type1 (or cff, which is just a more compact format of type1) | 16:22.51 |
| | paulgardiner: but I doubt the rest of smartoffice will be happy with raw CFF fonts (which is the smallest possible font format) | 16:23.18 |
| paulgardiner | I think SO can use CFF. I guess I must have known something about fonts back in the past: looks like I wrote the CFF interpreting code! | 16:28.14 |
| MacWinner | Hi, I am researching web PDF viewers. basically take a .PDF and convert it to HTML5 so it can be displayed on the web. PDFJS uses canvas element which I'm trying to avoid. They also have an SVG renderer, but it's not really well maintained. So now I'm looking for commercial solutions. I came across PrizmDoc and Foxit Web PDF viewer.. Any other recommendations? Is this something MuPDF can help with at all? | 17:32.55 |
| | I don't see a web viewer for MuPDF. is there one that I'm missing? | 17:34.56 |
| Robin_Watts | MacWinner: MuPDF is a native library. | 19:01.06 |
| | It can convert from PDF to a bitmap for you, which a browser could display, but that would rely on the browser being able to run a native plugin. | 19:02.03 |
| | It can (after a fashion) convert from PDF to SVG that many browsers can display. | 19:02.19 |
| | MacWinner: I have to confess not not entirely understanding what you are asking for though. | 19:03.44 |
| | pdf.js does the entire processing in javascript and writes to a canvas. As such it runs entirely without using native code | 19:04.41 |
| MacWinner | Robin_Watts, i have a user upload a PDF and I want to render it on a page using HTML5 (not using a regular PDF viewer). PDFJS renders it using an HTML5 CANVAS element which is not ideal for my use case.. | 19:05.04 |
| Robin_Watts | MacWinner: "Upload" as in "Uploads to your website" ? | 19:05.33 |
| MacWinner | correct | 19:05.38 |
| Robin_Watts | So, you could run native code on the server, and serve a bitmap back. | 19:05.56 |
| | (say a PNG) | 19:06.00 |
| | As such you can use almost any PDF viewer you like. MuPDF is certainly a candidate, and would give very nice results. | 19:06.47 |
| | The downside to this is that the free version of MuPDF is licensed under the GNU AGPL. | 19:07.17 |
| | Note the 'A' there. That means that if you're using MuPDF as part of a Software As A Service installation (and you would be), then you'd have to make the *entirety* of your software installation available under the GNU AGPL. | 19:08.03 |
| MacWinner | got it.. some of the tools like prizm and foxit render it nicely so people can highlight text and such | 19:08.10 |
| Robin_Watts | If you want to use it without that requirement, you'd need a commercial license. | 19:08.35 |
| | MacWinner: Interesting. I've not seen that. | 19:08.53 |
| | I wonder how they do that? Possibly by sending absolutely positioned HTML text invisibly which can be selected. | 19:09.31 |
| MacWinner | https://www.accusoft.com/demos/file-type-demo/ | 19:09.39 |
| | so you can search as well inside the doc | 19:10.04 |
| | and it will highlight the result in the doc | 19:10.26 |
| Robin_Watts | nice. | 19:11.33 |
| fredross-perry | tor8, sebras - is there a way to get mupdf (at least for Android) to render using RGB_565 bitmaps? | 20:51.22 |
| tor8 | fredross-perry: no, we can only render to 8-bpc formats | 22:38.52 |
| fredross-perry | ok thanks | 22:39.00 |
| | Forward 1 day (to 2018/02/16)>>> | |
Log of #mupdf at irc.freenode.net.