| | <<<Back 1 day (to 2016/07/17) | 20160718 |
| sebras | fredross-perry: I wasn't here when you asked me but I read the logs just now. | 04:05.43 |
| | fredross-perry: indeed the fid_Link_pointer and fid_Outline_pointer fields have been removed. The reason being that these two objects are now normal Java objects and no longer simply pointing to the fz_link and fz_outline data types. | 04:06.51 |
| | fredross-perry: does make nuke && make viewer resolve the matter for you? I'm thinking that the .so-library is out of date compared to the .java-files..? | 04:07.31 |
| | fredross-perry: I have no idea as to why the Makefile wouldn't pick this up though. :-/ | 04:07.57 |
| | fredross-perry: I'll check the logs in a couple of hours so if you (hopefully) make progress (or not), please leave a message here. :) | 04:10.39 |
| ruslan | Hi there. I want to ask does mupdf support printing? is there any example? | 12:30.40 |
| sebras | ruslan: I think the Android app using the MuPDF c library does support google cloud print | 12:48.12 |
| | ruslan: I haven't used it myself, but the code used in the sample viewer appears to be here: http://git.ghostscript.com/?p=mupdf.git;a=blob;f=platform/android/viewer/src/com/artifex/mupdfdemo/PrintDialogActivity.java;h=d96322d5215ac8c380cd5fd179eae3067b3a3327;hb=HEAD | 12:49.23 |
| | ruslan: seems like you are intending to use MuPDF in a project of yours? if you don't mind, can I ask what it is? it's always interesting for us to know where and how MuPDF is used. | 12:50.48 |
| malc_ | sebras: "int n = is.read(buffer);" should probably compete in a confusing category of some sort | 12:51.55 |
| sebras | malc_: because of the identifier named "is"? | 12:52.32 |
| malc_ | sebras: aye | 12:52.40 |
| sebras | malc_: I'm guessing it is an inputstream. but I haven't read all the code in the android parts. | 12:53.13 |
| malc_ | sebras: that'd be my guess too, but when i skimmed through the code first time that's not at all what i thought | 12:57.21 |
| ruslan | sebras: we building an ERP system. Documents are stored in SGML and for viewing we want to use mudpf. This would be a commercial project. | 13:00.14 |
| | actually I need a Desktop-compatible example... not mobile one | 13:01.29 |
| Robin_Watts | ruslan: If you get a commercial license sorted, we can then spend some time helping you out. | 13:02.02 |
| sebras | ruslan: MuPDF is available under two licenses. one being the open source license AGPLv3, the other being a commercial license. | 13:02.14 |
| Robin_Watts | MuPDF knows how to drive postscript and PCL printers. | 13:02.28 |
| | In both cases, it renders to bitmap data that is sent either wrapped as PS or PCL. | 13:02.57 |
| ruslan | yes i know. currently I'm in process of investigating witch library to use. | 13:03.09 |
| Robin_Watts | Cloud printing usually works by being sent a PDF. | 13:03.12 |
| | or PWG raster files (which MuPDF can also produce) | 13:03.34 |
| sebras | ruslan: for a commercial project I'm guessing you'd want a commercial license. e-mail sales@artifex.com to negotiate such a license. | 13:04.12 |
| Robin_Watts | ruslan: So, documents are in SGML, rather than PDF? | 13:05.46 |
| | So you'd be writing a new document handler? | 13:06.02 |
| ruslan | Robin_Watts: actually now because SGML is a Markup Language with now standards of describing a document structure. We have some internal standarts and some code to generate a pdf(using apache fop) | 13:08.42 |
| | *actualy no | 13:08.54 |
| Robin_Watts | ruslan: Right, so you export from SGML -> PDF and then use MuPDF to view the PDF. | 13:09.14 |
| ruslan | yes | 13:09.23 |
| Robin_Watts | It would also be possible to get MuPDF to view the SGML directly. | 13:09.32 |
| | MuPDF can read a variety of input files; PDF, XPS, epub, html etc. | 13:09.56 |
| | so adding another format is not too huge a job. | 13:10.10 |
| | Do you have any example files? | 13:10.21 |
| malc_ | Robin_Watts: i think you are underestimating SGML (and not every code can whack up a epub like reader in a short time, IOW not everyone is tor) | 13:11.19 |
| ruslan | Robin_Watts: here is some example http://pastebin.com/jBrpGs5a | 13:12.57 |
| Robin_Watts | Ah, tables. | 13:13.42 |
| | They are tricksy. | 13:13.49 |
| | Stick with your output of PDF for now :) | 13:14.07 |
| ruslan | sorry.. i don't understand. what do you mean by "Stick with your output" | 13:16.01 |
| | you want me to share an output of pdf generated? | 13:16.30 |
| Robin_Watts | ruslan: No, just ignore me. | 13:18.45 |
| | Doing simple layout is... simple. Hence reading SGML files would be fairly easy - except when you introduce stuff like tables, it gets much trickier. | 13:19.35 |
| | But you've clearly already solved all this for your SGML -> PDF output routines. | 13:19.59 |
| sebras | ruslan: do you know what kind of output you need for the printing? I'm guessing you need to print on Windows clients? | 13:25.35 |
| malc_ | sebras: 537a467dfd6392d70624805943ac65182ec881b4 just reinforces my point | 15:18.12 |
| sebras | malc_: so you're saying that if we just named the variable contentResolverInputStream (as appears to be customary in Java) then there would be no bug..? | 15:37.04 |
| | malc_: or am I missing something here? :) | 15:37.13 |
| malc_ | sebras: you are missing - "is.available" :) | 15:38.12 |
| Robin_Watts | how would changing the name of the variables to something that passes your taste-filter solve that bug? | 15:38.39 |
| malc_ | Robin_Watts: my point was that it's confusing to the casual reader nothing more nothing less | 15:40.05 |
| Robin_Watts | Right, so how does 537a467dfd6392d reinforce your point ? | 15:40.39 |
| sebras | malc_: I agree with you that using "is" as an identifier could be misleading, but only if you don't immediately think InputStream when you see it. maybe using is and os for streams _is_ customary in Java. i actually don't know. | 15:40.55 |
| malc_ | Robin_Watts: "then is.available() can report 0 bytes" to me this is confusing, hence reinforcement of the whole less than ideal naming point | 15:43.07 |
| | sebras: neither do i, been ages since i did any java | 15:43.17 |
| sebras | fredross-perry: hi! | 15:55.25 |
| | fredross-perry: did you manage to make nuke and recompile? | 15:55.44 |
| fredross-perry | hi, re-checking my steps now. | 15:55.47 |
| | It was not the java viewer though, it was an Android example app. | 15:56.13 |
| | and the java viewer was fine as I recall. | 15:56.34 |
| | so I think I did have the wrong .so file, so just re-checking now. | 15:57.53 |
| sebras | fredross-perry: oh. oh! I haven't even tried to compile the android app! but how can it already be using the Link and Outline objects before they were fully implemented? | 15:59.34 |
| fredross-perry | I grabbed your source just to give it a try, including latest JNI and java code. | 16:01.10 |
| sebras | fredross-perry: ok. did recompiling resolve it? | 16:13.43 |
| fredross-perry | no, I got a different error. trying to hunt it down now. I had built your code in a separate tree. I'm suspecting there's a path issue that's allowing the build to pick up the wrong file. | 16:15.22 |
| sebras | fredross-perry: oh.. I think I adapted all paths after rebasing onto your patch that stuffed com/artifex/blah/blah into platform/java/src... | 16:21.33 |
| | fredross-perry: let me know if I messed up somewhere and I'll fix it promptly. | 16:21.48 |
| fredross-perry | not those paths. I think it's an Android Studio thing. | 16:21.53 |
| | I made a copy of my tree and pulled your code into it. I think the AS project "remembered" it's old location and grabbed the .so from there. | 16:23.12 |
| | so now I am working off a clone of only your code and building from scratch. | 16:23.50 |
| sebras | fredross-perry: I see. yeah, there's probably an .ini or registry thing or something keeping the paths around. | 16:23.57 |
| fredross-perry | Right. | 16:24.07 |
| sebras | fredross-perry: why do tools not just use relative paths is beyond me. :) | 16:24.25 |
| fredross-perry | DUnno. | 16:25.10 |
| | And now it's fine. So no worries. | 16:25.21 |
| sebras | fredross-perry: sweet. you had me worried there for a while. | 16:25.59 |
| fredross-perry | Sorry | 16:26.13 |
| sebras | fredross-perry: I have a few additions to PDFObject.write*() and DisplayList.toStructuredText() sitting on my branch (not 100% finished). | 16:26.59 |
| | fredross-perry: besides what you've already got and these two. is there something more that you need in the immediate future? | 16:27.21 |
| fredross-perry | No thanks. | 16:27.35 |
| sebras | fredross-perry: cool, then I know I can fix the remaining js interfaces missing from java without stalling you. :) | 16:30.32 |
| fredross-perry | sweet | 16:30.40 |
| Robin_Watts | fredross-perry: I would assume that you will be needing form filling stuff eventually ? | 16:30.54 |
| fredross-perry | yes, eventually. | 16:31.03 |
| Robin_Watts | So at some point you'll need APIs for that. | 16:31.17 |
| fredross-perry | right. | 16:31.36 |
| Robin_Watts | Do you have all you need for searching etc? | 16:31.45 |
| | And making new annotations etc? | 16:31.53 |
| sebras | Robin_Watts: searching should already be present. | 16:31.54 |
| | Robin_Watts: at least what is there gives you a list of rects as hits. | 16:32.57 |
| | Robin_Watts: I'll focus on the missing interfaces. some also appear to exist in java but not in js. so I' | 16:39.26 |
| | I'm guessing I'll add those to js. | 16:39.34 |
| | following tor8s patterns of course. | 16:39.44 |
| Robin_Watts | cool. Feel free to refine the java stuff of course. The interfaces were just sketches to start with. | 16:40.04 |
| | Forward 1 day (to 2016/07/19)>>> | |
IRC Logs