| | <<<Back 1 day (to 2018/03/16) | 20180317 |
| sebras | tor8 (for the logs): in pdf_add_simple_font_widths() first starts out at 0, but if the very first element of encoding points to a glyph then first will be reset to 0, when the next glyph is found first will again be reset to i corresponding to that glyph in the encoding. this seems wrong, but in the encodings we currently supply the very first element in pdf_win_ansi, pdf_glyph_name_from_iso8859_7 and | 06:20.45 |
| | pdf_glyph_name_from_koi8u the first element seems to be _notdef. | 06:20.51 |
| | tor8 (for the logs): if first starts at -1 you can handle element 0 not being _notdef too. | 06:27.19 |
| | do we care? I don't know. :) | 06:27.29 |
| | tor8: in pdf_add_font_descriptor() why don't you fdobj = pdf_add_object_drop(ctx, doc, pdf_new_array(ctx, doc, 10)); like in pdf_add_cid_font_widths(){? | 06:28.57 |
| | I'm confused... you don't do that in pdf_add_descendant_cid_font() either..? i.e. allocate the PDF object and add it immediately. why? | 06:31.36 |
| | tor8: in "Update mutool create documentation with new font creation directives." why not netion that the default value is Latin? | 06:32.40 |
| | tor8: now I have reviewed up until "Add phony target to java makefile so it properly rebuilds the native lib." they look reasonable to me. | 06:44.32 |
| | tor8: on tor/wip "Fall back to PDF document handler if no handler is found." have you found a case where this matters? | 06:45.23 |
| | tor8: on tor/wip "Add more version number #defines." LGTM | 06:45.40 |
| | tor8: I like "WIP: Add convenience function to create and put new arrays/dicts.". :) | 06:50.30 |
| | Robin_Watts: am I correct in assuming that your fix for 697186 in libjpeg has not yet made it into v9c? | 07:19.53 |
| | Robin_Watts: I can't find any bugzilla or mailing list thing about this. | 07:32.36 |
| | Robin_Watts: so now when I looked into upgrading to v9c I can't because I don't know this fix. | 07:33.01 |
| Hufokus | Hello! I have a question about blocks. Have a look at the pic please: https://i.imgur.com/C7Z16Na.png This green rectangle just makes fz_stext_block provided by mupdf visible, so it's just visualization. You see, this block includes not only the big title, but also part of the plain text above. The main question is: is it a pdf structure/layout issue, or some mupdf's block analizer problem? Does mupdf use some block sticking\splittin | 11:44.50 |
| velix | tor8: I'm on Windows... hard to compile here ;) | 22:49.13 |
| | Forward 1 day (to 2018/03/18)>>> | |
Log of #mupdf at irc.freenode.net.
