| | <<<Back 1 day (to 2014/07/23) | 2014/07/24 |
| callamits | Hi All | 10:35.43 |
| | we are getting this error in mupdf for android : | 10:36.05 |
| | D/dalvikvm( 1105): Trying to load lib /data/app-lib/com.artifex.mupdfdemo-1/libmupdf.so 0xb2d39818 E/dalvikvm( 1105): dlopen("/data/app-lib/com.artifex.mupdfdemo-1/libmupdf.so") failed: dlopen failed: cannot locate symbol "strtof" referenced by "libmupdf.so"... W/dalvikvm( 1105): Exception Ljava/lang/UnsatisfiedLinkError; thrown while initializing Lcom/artifex/mupdfdemo/MuPDFCore; | 10:36.26 |
| | please help us not able to figure out any solution for this | 10:36.56 |
| | this is happening for ubuntu on running mupdf demo in emulator | 10:38.58 |
| kens | I'd suggest its probably an emulator problem then | 10:39.16 |
| callamits | actually just now we tried on google nexus 4 also | 10:39.59 |
| | same error is coming ... | 10:40.11 |
| kens | I can't help you with this, not my field. Have you built the standard MuPDF demo, following the instructions ? Does that work ? | 10:40.54 |
| callamits | yes we are actually trying MuPDF demo and following the instructions, compilation etc goes thru smoothly while running the app it gives this error | 10:42.18 |
| paulgardiner | Can you not call malloc in gs? Is there a gp_malloc or something like that? | 10:42.33 |
| kens | I'll have to pass then, I don't know enough to help | 10:42.34 |
| | paulgardiner : you need to use the correct memory allocator and call the appropriate allocation routine, what are you tryihng to do ? | 10:43.08 |
| | You don't want to call malloc as that uses the system malloc,not the built-in memory manager(s) | 10:43.31 |
| paulgardiner | My tmp file fix makes some alterations in gxclfile.c. I wrap a FILE * in structure. I need to allocate the structure. | 10:44.26 |
| govind_cool | hello, anybody is there who can solve problem for android? | 10:44.26 |
| paulgardiner | malloc seems to work mostly but not on Mac OS X | 10:44.42 |
| callamits | ok kens thx, any pointers will be most welcome ,,, | 10:44.52 |
| paulgardiner | Well, I'm seeing a strange failure on my Mac Mini | 10:45.08 |
| kens | chrisl can you help paulgardiner ? I'd get the memory allocaters wrong. | 10:45.09 |
| | paulgardiner : you need to use the non-gc-memory allocater | 10:45.41 |
| | SInce you *defintely* don't want this garbage collected | 10:45.52 |
| chrisl | paulgardiner: you mean gs_malloc? | 10:45.58 |
| paulgardiner | I'll pastebin the code and say what I'm seeing | 10:46.19 |
| | http://pastebin.com/MUngRsH8 | 10:47.24 |
| | To be honest it seems impossible to me that that could fail at ifile->f = f | 10:47.52 |
| chrisl | Yeh, don't use malloc - use the ghostscript memory manager(s) | 10:47.53 |
| kens | There's a problem there, you don;t have the memory context, you'll need to pass that in too | 10:47.53 |
| | paulgardiner : I can't see how it could fail that way, but.... You shouldn't be using malloc() anyway | 10:48.56 |
| govind_cool | can anyone solve this.....http://bugs.ghostscript.com/show_bug.cgi?id=695381 | 10:49.54 |
| paulgardiner | Where this is called from I have two gs_memory_t pointers, one called mem and the other datamem | 10:49.55 |
| | actually data_me, | 10:50.10 |
| | data_mem | 10:50.16 |
| kens | I *think* chris will correct me if I'm wrong, you want somehting like gs_malloc(mem->non_gc_memory, sizeof...)); | 10:50.27 |
| paulgardiner | What's the exact call I should make for allocation and freeing | 10:50.34 |
| kens | Oh, possibly thread_safe_memory would be better ? | 10:50.59 |
| paulgardiner | Thanks kens. And to free? | 10:51.04 |
| | Any one of these things will be accessed only by a single thread | 10:51.27 |
| kens | govind_cool : see the comments to callamits above | 10:51.36 |
| chrisl | gs_alloc_bytes(mem->non_gc_memory, size, "comment"); | 10:51.45 |
| | and gs_free_object(mem, ptr, "comment"); | 10:52.20 |
| govind_cool | I think its not the emulator's issue... is it bcoz of version??? | 10:53.11 |
| paulgardiner | chrisl: ta | 10:53.21 |
| chrisl | paulgardiner: for convenience, your IFILE structure could hold a gs_memory_t pointer which would be set to the allocator you use, thus you *know* you have access to that allocator wherever you might free the memory again. | 10:53.50 |
| paulgardiner | chrisl: good idea. Will do that | 10:54.32 |
| chrisl | paulgardiner: so, you'd do "ifile->mem = mem->non_gc_memory", then gs_free_object(ifile->mem, ifile, "comment") | 10:55.51 |
| paulgardiner | Ah!. So what type is mem->non_gc_memory? | 10:56.23 |
| kens | paulgardiner : why not jsut store mem ? | 10:56.45 |
| chrisl | kens: it's conventional for objects to store the allocator they were allocated with, not the parent allocator | 10:57.12 |
| paulgardiner | That's what I was planning until chrisl suggested storing mem->non_gc_memory. :-) | 10:57.17 |
| chrisl | paulgardiner: non_gc_memory should also be a gs_memory_t | 10:57.32 |
| kens | usually just sotres mem ..... | 10:57.36 |
| paulgardiner | I can see the sense of storing the actual alocator | 10:57.38 |
| | but I'm easy either way | 10:57.53 |
| chrisl | I only store the "parent" allocator if I'm going to need access to it later - otherwise I store the allocator used for the object | 10:59.00 |
| | paulgardiner: the main thing, as kens mentioned, is not to use garbage collected memory. And not to be fooled into thing that "stable_memory" is not garbage collected! | 11:01.49 |
| zapico20 | Hello, I'm trying to add a free text field to MuPDF in ios and I'm a little lost | 12:23.41 |
| Robin_Watts | zapico20: This is the right place. | 12:29.38 |
| | Ask your questions, but be prepared to wait a while for the answers, as people are in different timezones etc. | 12:29.56 |
| rayjj | paulgardiner: I saw your email. I assume that I should look at you git repo for these changes (on master branch). Is that correct ? | 15:04.12 |
| paulgardiner | rayjj: yeah that's correct | 15:05.00 |
| rayjj | paulgardiner: thanks | 15:05.12 |
| paulgardiner | np | 15:05.17 |
| | Still feels like a sledge hammer to crack a nut but seems to work | 15:05.45 |
| rayjj | paulgardiner: well, it seems more portable/maintainable than tryng to catch all exceptions and clean up after | 15:07.15 |
| paulgardiner | true | 15:08.04 |
| rayjj | IMHO, rather than delete on close, OS's need delete on process exit (or maybe in addition) | 15:08.17 |
| | paulgardiner: I'll try and get to it today. | 15:09.36 |
| Robin_Watts | rayjj: How would that work with fork on unix? | 15:11.46 |
| henrys | good thing tor isnât here mupdf just became 99 cents on ios | 15:15.50 |
| | weâll have to wait for the âWrath of Tor" | 15:16.15 |
| chrisl | Hmmm, scrabbling around for the odd dollar..... :-( | 15:16.55 |
| Robin_Watts | Next episode "The Search for Stiles" (where did Tor hide the body?) | 15:17.07 |
| henrys | I was the only one who didnât want run around with the tin cup but Iâm sure Iâll take the blame | 15:18.36 |
| jogux | henrys: possibly http://mupdf.com should be tweaked wrt to 'free', and possibly an email / contact place other than sales@ :-) | 15:19.22 |
| Robin_Watts | henrys: I disliked charging too. | 15:20.03 |
| | As I remember it was mainly Scott who was for it. | 15:20.12 |
| chrisl | I doubt we'll see much income from it - which is why we made it free to start with | 15:20.37 |
| henrys | jogux: does it take a while for the change to come into effect? I still see free. | 15:21.20 |
| jogux | henrys : yes, sorry, should have mentioned that. I think Apple say 24 hours, but past experience suggests it'll start appearing within an hour | 15:23.49 |
| rayjj | paulgardiner: I hope you don't ming that I took Bug 693121 and changed the status to "AWAITING_REVIEW" so that I don't forget to review your work. | 15:29.47 |
| | paulgardiner: I figured you were going to be sucked back into the SOT quagmire anyway | 15:30.10 |
| henrys | I think rayjj and michael were also in favor of charging for MuPDF? Can remember | 15:30.33 |
| | s/Can/Canât | 15:30.40 |
| | I never can remember anything I disagree with ;-) | 15:31.13 |
| paulgardiner | rayjj: not at all. appreciate it thanks | 15:31.59 |
| rayjj | henrys: I noticed you assigned the xpswrite issue back to me. Was that intended to have me change it to use an approach like what paul just did or the previously discussed gp_open_transient_scratch_file approach -- no comments were posted | 15:32.43 |
| paulgardiner | I'm not sure my approach will easily be applicable outside clist | 15:33.23 |
| | ... because of having to move away from using plain FILE* | 15:33.51 |
| rayjj | paulgardiner: right -- and the use of unbuffered IO that may be OK for clist usage may impact other clients (xpswrite/pdfwrite) more dramatically | 15:34.10 |
| paulgardiner | henrys: maybe we should take a new vote on MuPDF charging. | 15:34.30 |
| rayjj | paulgardiner: and I'd rather not have to do timing test for those devices | 15:34.35 |
| henrys | rayjj: yes I thought the current open_scratch_file should have the âtransientâ implementation and you should do something new for clist. But I donât feel strongly about it. | 15:34.39 |
| paulgardiner | rayjj: the use of unbuffered IO could be fixed by adding our own buffering. A bit fiddly but wouldn't be hard | 15:35.09 |
| henrys | paulgardiner: Iâll just tell miles there is a majority against, in engineering at least. | 15:36.13 |
| paulgardiner | The IFILE struct would be a natural place to hold buffers | 15:36.14 |
| rayjj | paulgardiner: right -- first I'll see if I can measure any performance diff, however. | 15:36.14 |
| paulgardiner | rayjj: yeah - sounds best | 15:36.33 |
| henrys | paulgardiner: I think that would be close to truth | 15:36.42 |
| rayjj | henrys: (and others) what do you think of overloading the "mode" for gp_open_scratch_file so that it uses a 't' in the mode to imply that "delete_on_close" (or immediate unlink) is acceptable to the client ? | 15:37.34 |
| | It's simpler than adding a new function | 15:38.05 |
| | chrisl: Robin_Watts: paulgardiner: please comment on this as well ^^^ | 15:38.27 |
| chrisl | rayjj: I'd be fine with that idea | 15:38.31 |
| rayjj | chrisl: thx | 15:38.36 |
| henrys | rayjj: Iâd be okay with that not my favorite choice but Iâm not doing the work ;-) | 15:38.47 |
| paulgardiner | henrys: yeah I think that's true. | 15:39.18 |
| rayjj | kens: any objection ? (I don't know if pdfwrite ever needs to be able to re-open temp files by name) | 15:39.25 |
| Robin_Watts | rayjj: I think I'd prefer a second function. Makes it more explicit, and saves having to have it scan the string/copy it etc. | 15:39.37 |
| kens | No sounds reasonable to me, pdfwrite never reopens temp files | 15:39.43 |
| rayjj | kens: thanks | 15:39.49 |
| paulgardiner | rayjj: I quite like the "t", but I'm known to have bad taste :-) | 15:40.20 |
| rayjj | paulgardiner: thanks. | 15:40.36 |
| chrisl | henrys: on the charging for mupdf subject, I'd be interested to know what changed from when we first discussed it: I seem to remember there being general agreement that the likely income was small, compared with the value of treating it as free publicity to attract OEM customers (also avoiding being morally obligated to provide end user support) | 15:40.50 |
| rayjj | at least it allows any existing clients that don't supply the 't' to work as now | 15:41.05 |
| kens | rayjj : so does having a different funtion though | 15:41.23 |
| rayjj | kens: right. But adding a function is more work and may imply to clients that it will always work (and I don't want to have to do gp_os2fs and gp_vms, or even gp_macio) | 15:45.04 |
| henrys | I do wish the transient thing were just names gp_tempfile - why do we have to have unfamiliar names for things? | 15:45.57 |
| | s/names/named | 15:46.25 |
| rayjj | henrys: have to ask LPD about that name :-) | 15:46.40 |
| chrisl | Yeh, bit late for that discussion henrys! | 15:46.55 |
| henrys | it depends if you decide to create a new function you can use âscratchâ for clist | 15:47.35 |
| chrisl | Ugh, I think it's worse having inconsistent names than strange ones..... | 15:48.14 |
| henrys | chrisl, paulgardiner Iâve written to miles and stated our objections | 15:48.26 |
| rayjj | having "scratch" for clist seems appropriate given the number of bugs ;-) Makes me itchy every time I look at the code | 15:48.53 |
| chrisl | henrys: as I said above, I'm genuinely interested in what inspired the change to charging for mupdf. | 15:49.36 |
| paulgardiner | henrys: good | 15:49.38 |
| rayjj | I better get back to cust 532's issues. mention me if you need my attention (or SMS) | 15:49.53 |
| henrys | chrisl: as Robin_Watts said I believe scott was the evangelist | 15:50.27 |
| rayjj | chrisl: on the issue of moral obligation for support for $0.99 -- I feel that we have satisfied our moral obligation by developing an ios app at all :-) | 15:51.33 |
| | but I don't think we will make much money, so it isn't a big deal. | 15:51.59 |
| chrisl | rayjj: psychologically, there's a big difference: people will complain more, and will expect more support for a 99c app than they will for a free app. | 15:52.28 |
| jogux | yep, they'll be onto scott demanding their money back :) | 15:52.45 |
| chrisl | My fear is that we may get more negative reviews | 15:53.14 |
| | Not because of quality problems, but because of intentional/known limitations in the apps | 15:54.02 |
| rayjj | chrisl: I agree about people's (unreasonable for $0.99 ?) expectations. I was just stating *my* sensation of "moral obligation" | 15:54.29 |
| henrys | chrisl: thatâs a concern and we just knocked mind share down an order of magnitude you never know where a reference will come from | 15:55.24 |
| paulgardiner | henrys: that's my bigest concern too | 15:57.03 |
| jogux | itunesconnect has some good figures for tracking "purchases" (whether free or not), so at least we should fairly quickly gather some hard data. | 15:57.38 |
| | s/figures/graphs/ | 15:57.48 |
| paulgardiner | Many engineers will have used MuPDF long before any need arises for it in their work. | 15:57.49 |
| rayjj | what's needed is a way to show "variable pricing" so that if a user has paid for a lot of apps, we show a nice high price (to imply value). That picks up people like Scott that think that price implies quality. For the rest of us, it's free ;-) | 15:58.04 |
| jogux | :-) | 15:58.20 |
| paulgardiner | A sort of "Pay what you deserve to" approach | 15:58.44 |
| jogux | rayjj: we could put up a mupdf premium build, say as free one but with a nicer splashscreen for 9.99 ;-) | 15:58.45 |
| | s/say/same/ | 15:58.51 |
| chrisl | henrys: IIRC, Scott was in favour of charging when the first app store discussion happened, too. So *something* has influenced Miles to change his mind - I'm willing to accept there may be a valid reason (rather than just Scott nagging a lot). | 15:59.05 |
| rayjj | jogux: right -- a splash screen with motion :-) | 15:59.15 |
| Robin_Watts | We should just put up 2 versions. One charged for and one not. | 15:59.58 |
| | Identical otherwise. | 16:00.10 |
| | If people want to support the development, they buy the charged for one. | 16:00.24 |
| | And that would capture people that want to pay for things, cos they never read the small print :) | 16:00.47 |
| chrisl | Robin_Watts: it depends if apple make that kind of thing difficult or not | 16:01.06 |
| rayjj | the free one could have a dialog you have to go past that advertises the paid one (that doesn't have the nag screen). That dialog could also mention Artifex Software and commercial licenses | 16:01.23 |
| Robin_Watts | chrisl: Screw ios users, they can pay :) | 16:01.51 |
| | I'm more worried about android. | 16:02.04 |
| rayjj | Robin_Watts: true -- they already pay extra | 16:02.10 |
| jogux | is very fussy about what iOS apps I pay for :-) | 16:02.25 |
| rayjj | jogux: as I am about Android apps | 16:02.41 |
| pedro_mac | or just do a time-limited version for free. That way people can eval the app, but pay if they want to use it ongoing | 16:02.44 |
| chrisl | Robin_Watts: "Screw ios users"? We'd have to get in-line behind apple ;-) | 16:03.02 |
| pedro_mac | thinks there are probably too many free competitors for that to be workable though | 16:03.08 |
| jogux | pedro_mac: that's not okay on iOS | 16:03.24 |
| rayjj | pedro_mac: I don't like that. Having it stop working in the future would really piss off a lot of people, IMHO | 16:03.28 |
| Robin_Watts | On android, we have lots of free mupdf-based competitors. | 16:03.28 |
| jogux | [apple don't allow "trial" versions] | 16:03.30 |
| Robin_Watts | On ios, we don't. | 16:03.47 |
| | hence charging on ios, but not on android does make some kind of sense. | 16:04.00 |
| pedro_mac | for iOS just charge - applefolks love paying for apps | 16:04.14 |
| chrisl | Apple tax | 16:04.32 |
| rayjj | pedro_mac: that was Scott's position, iirc | 16:04.41 |
| jogux | disputes that tbh. | 16:04.59 |
| | the top grossing apps in iOS are all free | 16:05.07 |
| | [well, not quite all. over 90%] | 16:05.39 |
| rayjj | grossing, in terms of downloads, not revenue | 16:05.42 |
| jogux | grossing in terms of revenue. | 16:05.51 |
| | people object to paying for apps but their seem to be lots of people that get manipulated into paying for in app purchases | 16:06.24 |
| | eg. top grossing app just now is 'clash of clans', some kind of game you play against your friends etc where you can use in app purchases to essentially buy currency to buy things so you can do better in the fights without learning the skill. | 16:07.47 |
| | but I don't know if that's appealing to the same kind of people that would use mupdf. | 16:08.31 |
| pedro_mac | yeah, buy document loading and saving credits. Saving credits cost 3x viewing credits | 16:08.49 |
| | not sure people would go for in-app with doc viewers | 16:09.06 |
| | but WeAreNotMarketingFolks ;) | 16:09.38 |
| Robin_Watts | one time unlocks for features like "printing" or "form filling" or "search". | 16:09.40 |
| | or "reflow" | 16:09.49 |
| jogux | or XPS viewing possibly. | 16:10.25 |
| rayjj | Robin_Watts: have to explain to a lot of people what "reflow" is | 16:10.29 |
| Robin_Watts | I already went through that with the translators :) | 16:10.52 |
| rayjj | Fixed on major leak in transparency code :-) (backdrop when knockout == true) | 16:14.44 |
| | s/on/one/ | 16:14.57 |
| Robin_Watts | nice. | 16:15.05 |
| | We should memento test some torture files. | 16:15.23 |
| jogux | robin_watts: can I not pass a branch name to git logg? | 16:15.36 |
| Robin_Watts | jogux: Urm... | 16:16.06 |
| | Evidently not. It seems to always list the whole lot. | 16:16.34 |
| rayjj | Robin_Watts: does memento report before gs does the heap_free_all (because that would free these) | 16:16.39 |
| Robin_Watts | Possibly cos git logg has --all in it? | 16:16.45 |
| jogux | ah. yes. removing that fixes it. | 16:17.22 |
| Robin_Watts | rayjj: It will report on atexit, but Memento_listAllBlocks() can be called at other points. | 16:17.24 |
| henrys | jogux: perhaps you want the range notation? | 16:18.07 |
| | bbiab | 16:19.28 |
| rayjj | Robin_Watts: Oh, I guess it does work by default. The gs_heap_free_all doesn't free all blocks if MEMENTO is #defined | 16:19.57 |
| Robin_Watts | ah, ok. | 16:20.12 |
| kens | Goodnight all | 16:23.44 |
| rayjj | for the next leak, I have to come up with a clean way to free anything allocated since a pattern clist playback with transparency pushed the device for the playback. | 16:41.26 |
| chrisl | Create a chunk allocator for the purpose? | 16:42.25 |
| rayjj | chrisl: not just freeing, but making sure that the p14dev->ctx is reset (I don't want dangling pointers). Since patterns can have complex drawing that may invoke other patterns, I have to unwind. I guess I need a stack | 16:44.12 |
| chrisl | rayjj: that does compp[ | 16:45.12 |
| | complicate matters.... | 16:45.18 |
| signnow | Good Morning from Los Angeles! | 17:08.09 |
| | I have a question about PDF coordinate system on Android. | 17:08.29 |
| rayjj | signnow: good morning (from Cypress, CA) | 17:08.32 |
| signnow | High Fi rayjj! | 17:08.48 |
| | If I load a image of any format (jpg, png, tiff) on Android activity, how do I convert the gesture listener's tap coordinates to PDF coordinate system? | 17:09.42 |
| rayjj | that's probably a question for Robin_Watts, paulgardiner, or mattchz | 17:10.15 |
| signnow | @Robin_Watts? | 17:11.27 |
| rayjj | signnow: but the question seems incomplete to me. Maybe it won't to them | 17:11.30 |
| signnow | I see. | 17:11.38 |
| | I need to solve a problem on Android platform. | 17:12.44 |
| | All I want to know if it is possible to convert a tapped location on screen into a PDF equivalent coordinates :) | 17:13.19 |
| Robin_Watts | Sorry, was just running the dog to the vets. | 17:23.47 |
| signnow | oh, hope the dog is ok! | 17:24.06 |
| Robin_Watts | signnow: Dog is fine thanks :) | 17:24.17 |
| signnow | Well, my question is : If I load a image of any format (jpg, png, tiff) on Android activity, how do I convert the gesture listener's tap coordinates to PDF coordinate system? | 17:24.17 |
| Robin_Watts | Let me have a quick look at the code. | 17:24.35 |
| | We have to do exactly this for annotations. | 17:25.02 |
| signnow | ok | 17:25.37 |
| | Also, this is not using MuPDF | 17:25.51 |
| | I want to load a image as it is, but somehow capture X & Y as accurately as possible to make it equivalent in PDF document | 17:26.24 |
| Robin_Watts | hmm. | 17:27.34 |
| | PDF pages can be different shapes and sizes. | 17:28.07 |
| signnow | I am trying to avoid using a PDF library altogether :| | 17:28.14 |
| Robin_Watts | A page might be (0,0) -> (400,600) say, where those numbers are given in points. | 17:28.41 |
| | Or it might be (100,100) ->(500, 700) | 17:28.55 |
| | so without a PDF library you can't know what the dimensions of the page are. | 17:29.23 |
| signnow | wow | 17:29.47 |
| | I see | 17:29.50 |
| Robin_Watts | Broadly speaking, most PDF pages tend to have sizes given in points (so 72dpi). | 17:30.35 |
| signnow | I see | 17:30.57 |
| | got it.. | 17:31.00 |
| | The downside of not using a PDF library is figuring out the coordination system. | 17:31.28 |
| | I really, really wish Android has some viewer library by default like iOS :( | 17:31.42 |
| | Suppose I user MuPDF, can I add annotation of native Android views like TextView on it? | 17:34.27 |
| Robin_Watts | MuPDF currently supports Highlight, Underline and Strikeout. | 17:35.59 |
| | and Ink annotations. | 17:36.05 |
| | We don't currently support text annotations, at least partly because we'd have to do something to figure out what fonts to use. | 17:36.28 |
| | but we have code to allow text to be added with form filling etc. | 17:37.04 |
| | I'm not sure I understand the question enough to give a better answer. | 17:37.17 |
| signnow | Well, your reply sort of answers my question. I wanted to know if I can add any type of Android View on a mUPDF rendered doc | 17:44.30 |
| Robin_Watts | I still don't see what you want. | 17:46.19 |
| | You want to be able to add new pages to a PDF document containing the content of an Android View? | 17:46.37 |
| signnow | nope | 17:46.52 |
| Robin_Watts | Or you want to be able to put a MuPDF document into an android view? | 17:46.55 |
| jogux | signnow: It might be better to explain with an example of why you would want to do this in your app | 17:47.15 |
| paulgardiner | Robin_Watts: actually, we support text annotations in the library, but not in the apps and only for base 14 fonts | 17:47.38 |
| signnow | Ideally, I want to be able to add Android views (like TextView, EditText, custom Android view that i can make like list view etc) | 17:48.50 |
| | I imagined, if I rendered a Imageview (convert PDF to image) & place all above mentioned Android views | 17:49.23 |
| paulgardiner | and this old branch has code added to the Windows app to test adding of text annotations: http://git.ghostscript.com/?p=user/paulg/mupdf.git;a=shortlog;h=refs/heads/freetext-test | 17:49.24 |
| signnow | But I need to figure out the PDF coordination system to get X, Y of any views I place on ImageView | 17:49.56 |
| Robin_Watts | signnow: These are sounding like android specific questions (I am not 100% sure what a 'View' is in android terms). | 17:50.00 |
| | Which means that paulgardiner is a better person to ask. | 17:50.11 |
| | <FX> Running feet, door slams, car starts, vroom! | 17:50.22 |
| paulgardiner | signnow: The existing app has to map view coordinates into mupdf library coordinates for various of its features. You can just copy how that is done | 17:51.43 |
| Robin_Watts | Given a rendered page being displayed by MuPDF, the app converts screen coords -> PDF coords, yes. | 17:52.30 |
| | but there is no concept of 'screen coords -> PDF coords' if you don't have an underlying PDF page. | 17:52.53 |
| paulgardiner | Robin_Watts: yes exactly. | 17:53.33 |
| | Looking at how in the android app the path of the user's finger is used to create an Ink annotation should tell you all you need to know. | 17:54.18 |
| signnow | I see | 17:54.47 |
| | I will try that out | 17:55.05 |
| | I have not heard back from Scott.Sackett@artifex.com about MuPDF licensing. | 17:55.39 |
| | Is that email address correct? | 17:55.44 |
| Robin_Watts | signnow: That certainly is the right email. | 18:05.10 |
| signnow | ok | 18:05.23 |
| Robin_Watts | signnow: Are you sumit ? | 18:05.39 |
| signnow | no | 18:05.48 |
| | what is that? | 18:05.51 |
| | oh, name? | 18:05.59 |
| | no, I am not Sumit | 18:06.06 |
| | I am Sireesha | 18:06.09 |
| Robin_Watts | Sorry, I had someone contact me this morning asking why Scott had not replied to their email. | 18:06.16 |
| signnow | lo, ok | 18:06.22 |
| | lol | 18:06.24 |
| Robin_Watts | It's hard to keep track of email contacts and irc when the names don't match :) | 18:06.32 |
| | Can you send your mail again please, and copy it to Henry.Stiles@artifex.com ? | 18:07.12 |
| | Ordinarily I'd volunteer to chase it for you, but I'm off on holiday soon, so I'd be a bad choice in this case. | 18:07.37 |
| | henrys will chase it for you. | 18:07.48 |
| | Sorry about this! | 18:07.54 |
| henrys | Robin_Watts: I did send a followup to scott along with suggestions about changing his email setup | 19:59.32 |
| rayjj | that email with the "performance results" from the potential customer is frustrating. Almost as much as the lack of response from company C with what they were supposed to send me (back in June) | 20:21.02 |
| mvrhel_laptop | rayjj: so you have heard nothing from company C? | 20:32.44 |
| rayjj | mvrhel_laptop: nope. Scott bugged them again last week (Mike Green). He didn't cc me, but forwarded it to me later, so I don't know if he got a reply. | 20:45.31 |
| | guess I missed mvrhel :-( | 20:46.15 |
| | the good news is that for cust 532 I didn't have a second leak issue -- it was all just the knockout backdrop buffer, so now the page (fts_25_2526) renders in a max memory of 16M including 4M (wasted during rendering) bufferspace and transparency buffers as well as memfile clist for the pattern (it was exceeding 80M before) | 20:49.45 |
| | funny. I somehow got on a TIFF email list | 21:21.00 |
| | Toronto International Film Festival :-) | 21:21.26 |
| | they probably have a tiff library ;-) | 21:22.28 |
| cats | anyone have some time to answer a quick MuPDF question? | 21:31.58 |
| Robin_Watts | cats: ask, don't ask to ask. | 22:20.59 |
| cats | Robin_Watts: alright, cool - I'm having trouble finding the appropriate library calls to extract fields from a PDF | 22:22.55 |
| | specifically, here: http://www.mupdf.com/docs/browse/include/mupdf/pdf/field.h | 22:23.20 |
| | pdf_lookup_field takes a pdf_obj instead of a pdf_document, and I'm not sure why that's the case | 22:24.24 |
| Robin_Watts | bear with me a mo. | 22:28.27 |
| | pdf_lookup_field is kind of an internal function. | 22:29.01 |
| | It's used by the js veneer and the form handling. | 22:29.40 |
| | As such it operates at the pdf_object level. | 22:29.54 |
| | paulgardiner and tor8 are the guys to talk to about this. Try here again in about 12 hours time. | 22:30.13 |
| cats | Robin_Watts: ok, will do. Thanks a lot | 22:35.50 |
| | where can I access form handling calls? | 22:36.13 |
| Robin_Watts | You need to ask paul or tor, sorry. | 22:38.27 |
| | If you can read JNI code, then you can look in platform/android/jni/mupdf.c for how the form handling is done in there. | 22:39.03 |
| cats | no problem, this has been helpful, and I'll be back to ask the other guys | 22:41.08 |
| | Forward 1 day (to 2014/07/25)>>> | |
IRC Logs