| | <<<Back 1 day (to 2020/12/03) | Fwd 1 day (to 2020/12/05)>>> | 20201204 |
| sebras | @ator ok, so it is possible to implement it in writeobject() by essentially setting crypt to NULL for signature objects. | 01:07.58 |
| | but that now means that verifying the signature fails since the Contents string is unencrypted. | 01:08.21 |
| | so it might be the case that we must encrypt the signature contents. I need to verify this with acrobat of course. | 01:08.58 |
| | oh and for _some_ encryption methods this means that the string is enlarged, which means that we need to know that when writing out all the objects, _before_ completing signatures.. | 01:09.50 |
| | pdfref doesn't state the signature strings should be exempt. | 01:14.55 |
| | from encryption. | 01:15.01 |
| | we do not encrypt the /Contents in the signature dictionary today. | 01:17.21 |
| | it might be the case that we should. | 01:17.39 |
| artifexirc-bot | <paulgardiner> Pretty sure we shouldn't. The signatures mupdf creates are accepted by AR, even for encrypted files. | 09:21.46 |
| | <paulgardiner> The only part of this that is actually given us problems is the test failing. I'd be tempted to remove the test. Once the encryption is removed we'll end up with a test for which failure is impossible. | 09:24.47 |
| | <paulgardiner> The only part of this that is actually giving us problems is the test failing. I'd be tempted to remove the test. Once the encryption is removed we'll end up with a test for which failure is impossible. | 09:44.23 |
| | <ator> @sebras @paulgardiner in pdf_signature_contents we get the Contents entry from the signature without any special handling. that means we are decrypting the string as usual! | 10:15.25 |
| | <ator> ah, no, it's too early in the morning. we are reading the V object using pdf_load_unencrypted_object! | 10:17.03 |
| | <ator> @sebras @paulgardiner ~~in pdf_signature_contents we get the Contents entry from the signature without any special handling. that means we are decrypting the string as usual!~~ | 10:17.38 |
| | <paulgardiner> I should add a proviso to my last statement: it is only the test failing that is giving us problems at the moment, but we might well see further problems if not for the fact that we always reload the document after saving (and so don't care about the state of the in-memory copy of contents after saving). I can see why you wish to improve on the current handling and take better care of the in-memory copy. | 10:55.22 |
| vtorri | ator i'm doing the search of a word. I have all the rectangles of the occurences | 11:02.12 |
| | ator is it possible to use fitz to display the rectangles on top of the pdf ? | 11:02.39 |
| | or should i use the gui i'm using ? | 11:02.49 |
| artifexirc-bot | <Robin_Watts> vtorri: Yes, that's possible. | 11:24.48 |
| | <Robin_Watts> You get a pixmap of the page drawn by pdf_run_page, (or fz_run_page, whichever) right? | 11:25.24 |
| vtorri | Robin_Watts is there an example somewhere ? | 11:25.25 |
| artifexirc-bot | <Robin_Watts> then you can open a new draw device on that, and call fz_fill_path etc to draw on top of it. | 11:26.01 |
| vtorri | fz_run_page | 11:26.18 |
| artifexirc-bot | <Robin_Watts> Actually, you probably already do: | 11:26.28 |
| | <Robin_Watts> pix = fz_new_pixmap | 11:27.12 |
| | <Robin_Watts> dev = fz_new_draw_device... | 11:27.12 |
| | <Robin_Watts> fz_run_page(dev, ...); | 11:27.13 |
| | <Robin_Watts> fz_close_device(dev); | 11:27.15 |
| | <Robin_Watts> ... | 11:27.16 |
| | <Robin_Watts> so before you do the fz_close_device, you can call other operations to draw onto the page. | 11:27.39 |
| vtorri | yes, i do this | 11:27.52 |
| artifexirc-bot | <Robin_Watts> Like fz_fill_path() | 11:27.55 |
| vtorri | interesting :) | 11:28.05 |
| | does fz_fill_path support transparency ? | 11:28.32 |
| artifexirc-bot | <Robin_Watts> That's what the alpha field is about, yes. | 11:28.42 |
| vtorri | i don't know this api | 11:28.54 |
| | going to look at it | 11:29.05 |
| | thank you | 11:29.22 |
| artifexirc-bot | <Robin_Watts> basically, fz_run_page interprets PDF and turns it into a series of "device" calls. | 11:29.22 |
| | <Robin_Watts> You can make all those device calls yourself. | 11:29.32 |
| | <Robin_Watts> so you can do anything that PDF can. | 11:29.44 |
| vtorri | very nice for a search | 11:29.45 |
| | Robin_Watts i'll try this, thank you | 11:33.37 |
| ator | vtorri: though in the end it's probably easier to display the rectangles in your GUI :) | 11:53.24 |
| | that's what we've ended up doing for all our viewers | 11:53.36 |
| | it also means we don't have to re-render the page if the search results change :) | 11:54.00 |
| | or for highlighting mouse selections, etc. | 11:54.15 |
| vtorri | ator ha, indeed | 12:08.13 |
| | ok, then i stick to my first idea | 12:08.35 |
| | ator thank you | 12:08.40 |
| clam | ator: (for the logs) fitz has trouble with the title of the following html "<title>й</title>й" do note that it is 0439 (cyrillic small letter short i) no diacritics involsved. the bady is rendered just fine. title does not contain the proper symbol at all | 20:07.18 |
| | i can't type, sorry 'bout that | 20:07.54 |
| | <<<Back 1 day (to 2020/12/03) | Forward 1 day (to 2020/12/05)>>> | |
Log of #mupdf at irc.freenode.net.