| <<<Back 1 day (to 2021/03/01) | Fwd 1 day (to 2021/03/03)>>> | 20210302 |
artifexirc-bot | <paulgardiner> Would someone please review the last two commits on my master branch. They are work towards generalising signature appearance streams. The changes these two commits bring in are to use the device interface, to update the text layout algorithm to work in that context, to break the fixed number of lines assumption for the certificate info, and to use a mupdf logo as the background water mark. Yet to do is alter the API to permit the f | 10:55.21 |
| <ator> @paulgardiner I think leakes new_ap_n in pdf_update_appearance_from_display_list | 14:20.57 |
| <ator> @paulgardiner I think that leaks new_ap_n in pdf_update_appearance_from_display_list | 14:21.03 |
| <paulgardiner> Oops! I'll fix that. | 14:22.02 |
| <paulgardiner> Fixed now. | 15:57.54 |
| <ator> @paulgardiner you could avoid the fz_var if you just did pdf_dict_put_drop with the new_ap_n | 16:08.42 |
| <ator> @paulgardiner "Try increasing line counts until the text fits" would that be the same as "Try decreasing the font size until the text fits"? | 16:13.19 |
| <ator> and what's the deal with xadj and yadj after showing the text? is it just centering the block of text? | 16:15.29 |
| <ator> you have the maxwidth and number of lines from break_lines already, would that not be enough to jsut show at the correct offset and not need to adjust afterwards | 16:16.30 |
malc_ | ator: any input regarding FT get advance noise i've mentioned the other day? | 16:26.32 |
artifexirc-bot | <ator> malc_: we could remove the glyph id from the warning message and then they'd be combined into one warning | 16:28.05 |
| <paulgardiner> I did wonder about pdf_dict_put_drop, but had no preference given we have a try/catch block, but yeah probably would be better. Line count increase does imply font size decrease, but it isn't quite the same. The nice thing about basing on line count is that it at least determines a font size without having to use some sort of arbitrary 5% or the like. A down side to it is that it doesn't necessarily find the best fit: you can calcul | 16:28.10 |
malc_ | ator: okay, who's fault is that btw? font creator? | 16:29.00 |
artifexirc-bot | <ator> @paulgardiner the increase to 4 and it fits in 3 is fine to me; I like the integer number of lines that fit in the box being all discrete and neat even if it has that weirdness | 16:29.51 |
| <ator> malc_: PDF creator, referencing glyphs that don't exist in the embedded font. | 16:30.43 |
malc_ | ator: gotcha, thanks | 16:31.21 |
artifexirc-bot | <ator> I've seen HiddenHorzOCR abused like this before | 16:31.30 |
malc_ | CreatorAdobe Acrobat Pro 9.3.4 | 16:38.37 |
| so... ahem Creator with a capital C indeed | 16:38.51 |
artifexirc-bot | <paulgardiner> I changed to using the "_drop" method and updated the "line count" comment to include ", which decreases the font size," | 16:42.39 |
| <ator> "Add a function to create an appearance stream from a display list" LGTM | 16:44.20 |
| <ator> the pdf-layout.c part of the next commit LGTM too | 16:44.27 |
| <ator> meeting's too distracting to look at the pdf-appearance.c part right now, will have a look tomorrow before the meeting | 16:46.29 |
macwinne_ | why would anyone choose to render PDF to PNG if they have the option to render to SVG? | 22:22.13 |
| is there some better quality or more predictable quality of rendering when rendering to PNG? | 22:22.42 |
| <<<Back 1 day (to 2021/03/01) | Forward 1 day (to 2021/03/03)>>> | |