| | <<<Back 1 day (to 2020/09/22) | Fwd 1 day (to 2020/09/24)>>> | 20200923 |
| Robin_Watts_ | sebras: You about? | 11:22.09 |
| sebras | Robin_Watts_: I am. I'm looking at the fax commit. | 11:27.32 |
| Robin_Watts_ | sebras: Do you have any java test code for the APIs? | 11:27.53 |
| | I have a customer asking about merging PDFs, and I've extended the java API so we should be able to code it. | 11:28.18 |
| | So I thought I'd try writing a quick test. | 11:28.52 |
| | And leveraging someone elses code that actually gets it up and running would save me a few minutes of googling. | 11:29.19 |
| | If you haven't, no sweat. | 11:29.29 |
| sebras | no, there is no test code at all. | 11:29.55 |
| | what I use to test the new APIs we add is the java desktop viewer. | 11:30.16 |
| Robin_Watts_ | rats. OK. Will go try to figure out how to write a java command line thing :) | 11:30.28 |
| | Thanks. | 11:30.34 |
| | I thought the fax commit had gone in? | 11:30.55 |
| sebras | public static void main(String args[]) { } | 11:30.58 |
| Robin_Watts_ | sebras: That's a very useful start. Thanks :) | 11:31.23 |
| sebras | Robin_Watts_: nope, it's not in yet. | 11:31.39 |
| | Robin_Watts_: it turns out that pdfium is best in class in decoding the test file supplied with the fax bug. | 11:32.11 |
| | better than acroread. | 11:32.18 |
| Robin_Watts_ | and if we fix ours we match it? | 11:32.38 |
| sebras | if we take the supplied patch we improve, but not to pdfiums level. | 11:34.25 |
| | we're better than acroread at leat. | 11:34.33 |
| | least. | 11:34.35 |
| Robin_Watts_ | "make java" appears to leave loads of *.class files next to the *.java files. | 12:18.58 |
| | it makes a build/java/ thing with the com/artifex/mupdf/fitz directory tree in, but with no directories. | 12:19.35 |
| ator | make java should put the JNI object files in build/java/* | 12:21.50 |
| Robin_Watts_ | ok, ignore me. | 12:22.06 |
| ator | the class files unfortunately go next to the .java files, but that's the way java likes to work :( | 12:22.26 |
| Robin_Watts_ | I'm seeing class files in build/java/com/artifex/mupdf/fitz now. | 12:23.02 |
| ator | oh, right you are | 12:23.54 |
| | it's been a while, may have managed to coax it into doing that | 12:24.03 |
| | and the .class files I have left in platform/java/src/com/... are probably remnants from before then | 12:24.44 |
| Robin_Watts_ | ator: right. | 12:24.54 |
| ator | the platform/java/Makefile seems to support that, we pass -classpath ../../build/java to javac | 12:25.35 |
| Robin_Watts_ | Unfortunately, the jar file in build/java contains: build/java/com/artifex/mupdf/fitz/*.class for me, which doesn't work. | 12:27.29 |
| ator | Robin_Watts_: uh, yeah... that seems wrong | 12:31.05 |
| | I suspect we've never tested the actual jar file :/ | 12:31.39 |
| | the example viewer just runs with classpath=../build/java | 12:32.11 |
| Robin_Watts_ | I have a fix here. | 12:35.20 |
| | We can Document x = Document.openDocument("foo.pdf") | 12:35.43 |
| | but we can't PDFDocument x = PDFDocument.openDocument("foo.pdf"); | 12:35.57 |
| ator | if (doc.isPDF()) PDFDocument pdf = (PDFDocument) doc; | 12:36.33 |
| Robin_Watts_ | Right, but it seems a strange omission. | 12:36.57 |
| ator | static methods and inheritance are awkward | 12:37.02 |
| | or at least I think that we ran into some trouble trying that, overloading the same function name with a different return type didn't work | 12:38.20 |
| Robin_Watts_ | yeah, that sounds plausible. | 12:39.20 |
| ator | that said, I'm not averse to have a PDFDocument.open(PDF)Document factory method for when you know you only want PDF files | 12:40.23 |
| | the need just hasn't come up yet | 12:40.45 |
| Robin_Watts_ | ator: Ah, that'd be nice. | 12:43.13 |
| | ok, my test program is now dying looking for mupdf_java32, where we have mupdf_java64. | 12:46.46 |
| | Will dig more after lunch. | 12:46.52 |
| | ator, sebras: OK, my test app works, so those commits on robin/master are good to go too. | 13:59.01 |
| | ator, sebras: Anything I can be doing to help prepare for the release? | 13:59.28 |
| ator | I see you've added const back to the pixmap struct in a number of places | 14:18.38 |
| Robin_Watts_ | I have. | 14:21.05 |
| | Well, various params to functions now take const fz_pixmaps. | 14:21.27 |
| ator | "(1 = first page)" is contrary to all the other uses in the API | 14:21.52 |
| Robin_Watts_ | ator: ah. I copied that from pdfmerge. | 14:22.22 |
| | I can change that. | 14:22.26 |
| ator | I regret having internal page numbers start from zero ... that has been such a pain in the behind these last two decades :( | 14:23.17 |
| malc_ | so news that Fortran exists finally reached .se ... good good | 14:24.36 |
| ator | Robin_Watts_: if you take the page_to verbatim, you can also use -1 to mean "last page" and all the other conveniences of pdf_insert_page | 14:26.15 |
| Robin_Watts_ | ator: RIght. I'll fix that now. | 14:26.41 |
| ator | Robin_Watts_: oh, it's even more magic than that... | 14:27.11 |
| | or the comment needs fixing | 14:27.47 |
| | ah, no, I'm confusing myself | 14:28.54 |
| Robin_Watts_ | Commit updated. | 14:34.18 |
| sebras | ator: hm. I think that we're not guaranteed to have as many bit available as we need to eat in the alignment bit eating code. | 14:56.36 |
| ator | Robin_Watts_: LGTM, with some griping about "parse_declaration_list" stupid compiler warnings :) | 14:57.08 |
| sebras | i.e. a call to fill_bits() should probably happen before we try to eat, right? | 14:57.10 |
| ator | sebras: which line? in the changed code or elsewhere? | 14:57.42 |
| sebras | in the changed code. | 14:58.25 |
| | before line 727 I think., | 14:58.37 |
| | consider the case were at loop: we encounter an EOL followed by a dimension bit. | 14:59.06 |
| | we'll detect and read those. | 14:59.16 |
| ator | you mean if eat_bits eats more bits than are available in the 'bit buffer'? | 14:59.18 |
| sebras | y | 14:59.23 |
| | in fax->word | 14:59.30 |
| | I think the previous code might have had the same issue. | 14:59.49 |
| | because fax->bidx might be == 31 at this point. | 15:00.07 |
| ator | we are guaranteed to have at least 13 bits | 15:00.19 |
| | see fill_bits | 15:00.24 |
| sebras | didn't we eat those at lines 593 and 604? | 15:00.56 |
| | I know that fill_bits() guarantees 13 bits. | 15:01.54 |
| | but we need to call that again after eating the EOL+dim bits, right? | 15:02.14 |
| ator | there are many ways to end up in "label eol:" | 15:03.22 |
| | so yes, seems like the eat_bits may need to fill_bits to eat them | 15:04.42 |
| sebras | I think we should have a fz_warn() on line 734. | 15:05.33 |
| | because we're side stepping the encoded by align value supplied by the PDF. | 15:05.49 |
| ator | we could have a warning there, yes | 15:06.04 |
| sebras | and that guess might be wrong for other files. | 15:06.04 |
| ator | I hate this bit-reading code... | 15:07.11 |
| sebras | it is super nice. | 15:07.27 |
| | I think I've seen what pdfium is doing. | 15:07.40 |
| Robin_Watts_ | ator: which commits lgty? | 15:10.30 |
| | I think we're still waiting for sebras to be happy with the jpx one, right? | 15:11.06 |
| | I can rebase that to the end until he has time. | 15:11.16 |
| sebras | I'm clustering the addition of fill_bits() and the fz_warn() I added. | 15:24.46 |
| | behaviour is identical for the file attached in the bug report. | 15:25.05 |
| Robin_Watts_ | for both pdfium and your patched mupdf? | 15:38.08 |
| | i.e. both gold standard? | 15:38.14 |
| sebras | nope. | 15:39.14 |
| | int to_eat_old = (8 - fax->bidx) & 7; doesn't seem right to me. | 15:40.08 |
| | this is the original to_eat from the patch. | 15:40.33 |
| malc_ | you guys sure know how to name your variables... | 15:40.50 |
| sebras | it will produce values in the range 0..7 even if bidx is < 24. that can't be right. | 15:41.02 |
| ator | Robin_Watts_: LGMT MSVC: Add mujs source files to project. | 17:36.38 |
| | Robin_Watts_: LGTM Avoid warning in parse_declaration_list. | 17:36.54 |
| | LGTM Add some consts in the pixmap conversion functions. | 17:37.02 |
| | LGTM Add some consts to various fz_pixmap functions. | 17:37.11 |
| | LGTM Ensure libmupdf.jar gets correct path to class files. | 17:37.22 |
| | LGTM Add pdf_graft_mapped_page() function. | 17:37.56 |
| | though I'll want to add that function to mutool run as well | 17:38.14 |
| Robin_Watts_ | Ok, I've rebased the jpx one to the end. | 17:38.40 |
| | so I have a prefix I can push now. | 17:38.48 |
| | I won't push them for a bit, as Ray is waiting for a release test. | 17:38.59 |
| | I can either push the graft one now, or wait for you to add mutool run to it as you prefer. | 17:39.23 |
| ator | Robin_Watts_: wait with the graft one, I'll add it to mutool run | 17:40.31 |
| | that's already throwing me one complication -- the explicit src document in pdf_graft_mapped_page | 17:40.48 |
| Robin_Watts_ | That has to be there I believe, cos we don't set map->src at creation time, but on the first object copied. | 17:42.18 |
| ator | yeah, I'm realizing that now too | 17:44.05 |
| | what monkey designed this api? :) | 17:44.10 |
| | Robin_Watts_: one commit on tor/graftpage | 17:51.55 |
| | and it seems to work with a simple JS test script | 17:55.59 |
| Robin_Watts_ | ok, sorry, looking now. | 18:28.22 |
| | ator: Ah, so I need to expose pdf_graft_page through java. | 18:29.51 |
| | ator: I've rolled your commit into mine and exposed the new function too. | 18:52.41 |
| ator | Robin_Watts_: mupdf_native.h needs updating too | 21:32.16 |
| | it's not exposing PDFDocument.graftPage | 21:32.34 |
| | <<<Back 1 day (to 2020/09/22) | Forward 1 day (to 2020/09/24)>>> | |
Log of #mupdf at irc.freenode.net.