| | <<<Back 1 day (to 2017/11/30) | 20171201 |
| tor8 | one commit on tor/master for review | 14:36.30 |
| | Robin_Watts: sebras: ^ | 14:36.43 |
| | an alternative way would be to just stop parsing the number at a non-digit and ignore the requirement for whitespace/delimiter characters separating tokens | 14:38.37 |
| sebras | tor8: did you cluster the fix for 698785? I'm worried that it might cause other PDFs to now fail..? | 16:50.01 |
| RobinWattsLenovo | tor8: what about 135e3 ? | 16:50.09 |
| | e is a special case, is my point. | 16:50.32 |
| tor8 | RobinWattsLenovo: scientific notation numbers aren't allowed in PDF | 16:52.19 |
| RobinWattsLenovo | ok | 16:52.53 |
| sebras | tor8: new version of "Fix 698785: Catch malformed numbers in PDF lexical scanner." lgtm. | 17:32.27 |
| | tor8: "Fix 698787: avoid using "system()" to copy files." writes to the output file before validating the return value of the read call. I'm not sure if fwrite() would handle a negative nmemb. | 19:41.38 |
| | tor8: conceivably it would attempt to read more bytes than we have in the buffer. | 19:42.07 |
| tor8 | sebras: I don't think fread can return a negative value | 19:47.23 |
| sebras | tor8: right, I misremembered that it returned -1 upon error. | 19:49.31 |
| | tor8: I assume that supplying 0 would be handled though. | 19:50.17 |
| tor8 | more worrying is that the caller of windocopy doesn't check for errors... | 19:51.11 |
| sebras | tor8: wincopyfile(), but yeah. | 19:52.20 |
| | tor8: that would be an issue if the file couldn't be fully copied. | 19:52.36 |
| tor8 | I also have a nagging suspicion that all this juggling should be done as part of doing an incremental pdf_save_document, automatically | 19:53.24 |
| sebras | tor8: true. | 19:53.45 |
| | tor8: but we'd need an argument to pdf_save_document() or add a new pdf_save_incremental_document() so we know how to do it. | 19:54.43 |
| tor8 | maybe we should split incremental saves from full saves by using a separate function rather than doing magic stuff based on the pdf-write-options | 19:55.05 |
| | pdf_update_document to do an incremental save of the diffs, and pdf_save_document writes a brand new document | 19:55.31 |
| | not sure, will need to think about it some more | 19:55.39 |
| sebras | tor8: the only reason do separate them is if there is some kind of incompatibility between incremental updates and the current set of write-options. | 19:56.39 |
| tor8 | currently I think it crashes if you set 'incremental' to true but haven't saved the document fully first... | 19:57.31 |
| | I can't remember if I fixed that or not... | 19:57.47 |
| sebras | tor8: other than that it is mostly aquestion about what feels nice designwise. | 19:58.11 |
| tor8 | pdf_save_document(doc, filename) vs pdf_update_document(doc). | 19:58.43 |
| | or pdf_save_document_changes(doc) | 19:59.04 |
| sebras | tor8: do we want to separate changes to annotaitons, form contents from other changes..? | 20:00.16 |
| | tor8: they are currently also labelled "changes". | 20:00.36 |
| | Forward 1 day (to 2017/12/02)>>> | |
Log of #mupdf at irc.freenode.net.