| | <<<Back 1 day (to 2018/02/22) | 20180223 |
| ildar | Hi everybody! Some source says that Android Viewer has less vulnerabilities/CVE then MuPdfDemo. Is this correct? I can't find proofs/info | 09:13.02 |
| kens | It would seem unlikely, since tehy are built on the same core library | 09:15.54 |
| ildar | a-ha! thanks. | 09:16.15 |
| | I suspected that | 09:16.23 |
| kens | Note that I'm not one of the MuPDF developers, so I can't give a definitive answer | 09:16.50 |
| ildar | BTW do you know why Android Viewer misses Reflow mode? | 09:20.56 |
| kens | Sorry, I can't help ,but the various viewers all have different capabilities | 09:21.17 |
| ildar | FYI https://bugs.ghostscript.com/show_bug.cgi?id=699062 | 09:32.29 |
| tor8 | paulgardiner: Robin_Watts: to get a more specific name than what freetype has managed to load into the family+style names you might need to start digging into the SFNT name tables | 10:43.32 |
| | https://www.freetype.org/freetype2/docs/reference/ft2-sfnt_names.html | 10:43.33 |
| | there is very little consistency in font family/style naming conventions--seems like every font family has its own way of naming things | 10:44.13 |
| | for the base14 we have a long list of aliases we scan for (see base_font_names and clean_font_name in pdf-font.c) | 10:44.54 |
| | you probably want a fuzzy matcher along those lines (or just hard code a font file you know is there, along with its TTC index) | 10:45.36 |
| | I think Robin's suggestion of if (family is prefix of style) name=style else name=family+style should work well enough | 10:46.52 |
| | in order to access the name IDs Robin listed, you need the API I pasted a link to above | 10:48.43 |
| | but I'd rather not start digging into those in the mupdf core | 10:49.03 |
| ildar | guys, I'm lost in MuPdf4Android roadmap | 11:07.36 |
| | 1. Is MuPdfDemo abandoned? | 11:07.56 |
| | 2. What's the Fitz thing? | 11:08.19 |
| tor8 | 1. Pretty much. | 11:29.58 |
| | 2. Fitz is the code name for the original graphics rendering library used in MuPDF. | 11:30.09 |
| ildar | Then the only 2 things left are Viewer and Mini ? | 11:30.45 |
| | BTW latest Play Market apps have CVEs | 11:31.24 |
| | that's bad! | 11:31.31 |
| tor8 | The "Viewer" is a stripped down version of the MuPDF demo code base, refit to use our new JNI library. | 11:31.32 |
| ildar | MuPdfDemo status changes should be wrote somewhere. I couldn't find any info on that. | 11:33.07 |
| | should be written | 11:33.27 |
| | ⺠| 11:33.34 |
| tor8 | it still works. it's just not getting any new features and updates. | 11:33.47 |
| ildar | emm. You mean build it with new Fitz code? | 11:34.30 |
| | BTW does 1.12 fix 1.11 CVEs ? | 11:35.24 |
| tor8 | 1.12 fixes many bugs. whether these have CVEs or not, I can't be bothered to keep track. a bug is a bug and needs squishing whether it has a stupid CVE number or not. | 11:36.22 |
| ildar | oh, ok. | 11:36.49 |
| paulgardiner | tor8: re font names, how about if I added fz_font_style that returned the style string? Then the caller could decide how to match based on both family and style. I'd prefer if we could pick out the full name from the font, id 4 I think it was, but it sounds like that isn't straight forward, from what both you and Robin say. | 11:36.56 |
| tor8 | paulgardiner: I don't think we use the fz_font_name for anything non-cosmetic so mashing them together shouldn't affect anything significant | 11:37.33 |
| ildar | so generally building MuPdfDemo with fresh Fitz is quite possible and still quite good? | 11:37.50 |
| tor8 | it might change how we write SVG and some debugging info though | 11:37.50 |
| | paulgardiner: and I would prefer to have the full name as well | 11:38.24 |
| paulgardiner | Yes, but picking a particular way to combine family and style into a name gives less info than providing separate access. | 11:38.34 |
| tor8 | paulgardiner: right. I have no objections if you want to add an accessor | 11:38.56 |
| | maybe one that removes a common prefix when setting the 'style' name? | 11:39.11 |
| paulgardiner | tor8: oh, hang on, you'd prefer the full name? Should I look into that a little further? | 11:39.26 |
| ildar | tor8: please? | 11:40.58 |
| tor8 | ildar: some features don't work properly anymore (I suspect due to changes/breakages in the android system libraries) | 11:42.24 |
| paulgardiner | tor8: regarding the option of adding an accessor for style, I'm confused about the whole prefix thing. I haven't seen examples of common prefixes. | 11:42.34 |
| tor8 | but if you build with an older android toolchain it might | 11:42.40 |
| ildar | I see. Thanks. | 11:43.26 |
| tor8 | ildar: printing and reflow mode don't work last I tried | 11:45.19 |
| ildar | ⺠| 11:45.30 |
| | then it's no better then the Viewer | 11:45.48 |
| | ok, I see | 11:46.02 |
| tor8 | it can do some annotation editing, but other than that it's pretty much the same yeah | 11:46.26 |
| ildar | thanks | 11:46.38 |
| paulgardiner | tor8: there's a commit on my master concatenating family and style, I think using the conditions suggested. I'm about to cluster test. | 13:01.42 |
| tor8 | paulgardiner: "its name" not "it is name" please :) | 13:10.05 |
| | paulgardiner: also, I think you can just get away with a fixed length buffer and fz_strlcpy/fz_strlcat for this | 13:10.21 |
| | the font->name is just an array anyway | 13:10.31 |
| | the fz_set_font_bbox has weird indentation after you edited it | 13:11.25 |
| | the function call to fz_set_font_bbox | 13:11.33 |
| paulgardiner | How bit a buffer would you suggest? | 13:13.53 |
| tor8 | 200 bytes should be more than enough | 13:14.13 |
| paulgardiner | Okay | 13:14.17 |
| tor8 | or just use buf[sizeof font->name] :) | 13:14.33 |
| paulgardiner | The "it is" thing is just weird... a little worrying! | 13:20.08 |
| | tor8: second version up | 13:54.15 |
| tor8 | paulgardiner: s/namebuflen/sizeof namebuf/ in the strlcpy/cat function calls, otherwise LGTM | 14:13.18 |
| | paulgardiner: do you remember where you got the outline/vector/icon thing for the annotation icons? | 14:13.36 |
| | the speech bubble icon | 14:14.20 |
| paulgardiner | I think I made it with GIMP | 14:27.22 |
| | I think I still have the GIMP file | 14:27.35 |
| | tor8: what's the namebuflen thing? You mean don't put in a variable? | 14:28.13 |
| | Oh I see yes. Stupid stupid | 14:29.39 |
| fredross-perry | tor8 - is there a way in mupdf to stop a long-running render? Let's say I have two threads, A and B. B is running a long render, can thread A interrupt it? | 15:05.27 |
| tor8 | fredross-perry: that's what the cookie is for | 15:17.52 |
| fredross-perry | more please? | 15:18.17 |
| tor8 | Page.run takes a Cookie argument | 15:18.49 |
| | if you call cookie.abort() from another thread that should set a flag to let the interpreter know to abort the render | 15:19.22 |
| | this is untested territory, but it should work | 15:19.59 |
| fredross-perry | got it, thanks | 15:20.09 |
| tor8 | you might need to do some plumbing to add the cookie argument if you're not calling page.run() directly | 15:20.45 |
| fredross-perry | I am calling page.run(), so good, thanks. | 15:22.07 |
| | Forward 1 day (to 2018/02/24)>>> | |
Log of #mupdf at irc.freenode.net.