| <<<Back 1 day (to 2015/11/18) | 20151119 |
Nathaniel7687 | hi | 08:20.43 |
ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 08:20.43 |
Nathaniel7687 | how can I ndk-build mupdf for android about armeabi, not armeabi-v7a? | 08:21.54 |
kens | Nathaniel7687 : I'm afradi you'll have to wait a couple of hours before anyone who can answer that is likely to be online | 08:22.26 |
| Either hang around for a bit, or come back later and look at the channel log (see the topic for the URL of the logs) | 08:22.54 |
Nathaniel7687 | kens : You're autobot? | 08:23.24 |
kens | Nope | 08:23.35 |
| Kind of an intelligent answer for a bot I would like to think | 08:23.47 |
Nathaniel7687 | thanks~ | 08:23.47 |
| good | 08:24.09 |
| I find solution | 08:37.10 |
| thanks | 08:37.14 |
kens | faLUCE : here's a zip file with 3 files in it, the original, and 2 modified versions where I've manually hacked thje MediaBox and CropBox so that you can see only 1 of each page. | 09:26.24 |
| https://www.dropbox.com/s/m8n9vic5qjfet9q/scannedpages.zip?dl=0 | 09:26.30 |
| Because your file solely consists of an image, there is no way to do any better just by modifying the PDF, in order to reduce the file size you would need to edit the image and your best bet for that is to extract it from the PDF, modify it in an image package and then re-export back to PDF. | 09:27.22 |
| Since you are reluctant to do that, this is the next best solution. | 09:27.35 |
| Now since I was hand hacking these files I was able to amke sure that the number of bytes in the MediaBox is always the same, which means the files remain valid PDF. If you were to use some scripting language or programmatic method to alter teh MediaBox then you would likely end up with differences in the size of the MediaBox. | 09:28.47 |
| So to fix that you would use mutoll clean as I suggested last night. | 09:29.01 |
Robin_Watts | Nathaniel7687: For the logs: Presumably you can build for arm-v7a already? To build for armeabi instead, just change the lines that are commented in/out setting APP_PLATFORM and APP_ABI in platform/android/jni/Application.mk | 09:47.48 |
HenryStiles | kens: another failure on i7? | 14:14.36 |
kens | Is there ? | 14:14.51 |
HenryStiles | mprimes is still going I'm going to stop it soon | 14:14.51 |
| kens: asking if you've seen another | 14:15.10 |
kens | I looked at marcos' report and there are (or were) 4 seg faults there, all on i7 | 14:15.17 |
| Oh yeah there are 5 now | 14:15.38 |
| Different jobs, different devices, different resoltuoins, even different input languages | 14:17.04 |
| The only common actor seems to be the node | 14:17.41 |
HenryStiles | mprimes has been going for almost 24 hours now, so I wonder what it could be? | 14:17.52 |
kens | is baffled | 14:18.01 |
HenryStiles | I'm probably being daft but why doesn't /join #artifex not work? | 14:29.45 |
kens | It should, does for me | 14:30.02 |
| THat is your registered nick ? | 14:30.33 |
HenryStiles | | 14:30.41 |
| it's saying #artifex: Cannot join channel (+r) - you need to be identified with | 14:34.12 |
| services | 14:34.13 |
kens | I thnk that meyour nick isn't registered | 14:34.26 |
| try leaving ghostscript and rejoining, I thnk ray had that kind of problem | 14:34.44 |
marcosw1 | HenryStiles: I get the same message will quit and restart pidgin | 14:50.33 |
Nathaniel7687 | hi | 16:28.00 |
ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 16:28.00 |
Nathaniel7687 | I have some problem that error message "Out of memory during layout" about "java.lang.outofmemoryerror: bitmap size exceeds vm budget". | 16:29.02 |
| in Android | 16:29.11 |
| how can I solve this error. | 16:29.22 |
HenryStiles | Nathaniel7687: you've ported gs to Android? | 16:49.02 |
| Nathaniel7687: oh this must be mupdf? | 16:49.51 |
kens | MuPDF see this morning's logs | 16:50.24 |
Robin_Watts | Nathaniel7687: Are you using our MuPDF source exactly as we supply it? Or are you importing it into your own project and modifying it? | 16:57.31 |
Nathaniel7687 | I'm importing it into my own project and modifying it. | 17:43.06 |
| I'm not modifying mupdf package. | 17:44.55 |
| I just open pdf file in assets folder. | 17:44.59 |
Robin_Watts | Nathaniel7687: The app doesn't support opening a pdf file from the assets folder. | 17:47.06 |
| Therefore you must be modifying the app at least a bit. | 17:47.26 |
| If you can show us the problem happening with the original source that we supply, built using the makefiles etc that we supply, we might be interested in looking into it. | 17:47.58 |
| If it's going to require us to understand your (say) android studio project to reproduce the problem, then we don't have time, I'm afraid. | 17:48.54 |
Nathaniel7687 | I find one specific condition. | 17:52.29 |
| This problem is appear Android 2.3.7(API 10) | 17:53.22 |
| because my emulator's heap memory allocated lack, I think "Out of memory during layout" message appear. | 17:56.00 |
| the others emulator(kk 4.1.1, lp 5.1.0) is not appear this message. | 17:56.51 |
Robin_Watts | Nathaniel7687: It might well be due to a lack of memory. What size memory are you working with, and what screensize ? | 17:59.37 |
Nathaniel7687 | 800x1280, 320dpi heap memory size 32mb | 18:00.09 |
Robin_Watts | 800x1280 requires 4Meg(ish) for a single screen sized bitmap. | 18:00.47 |
Nathaniel7687 | heap size it's so low? | 18:00.49 |
Robin_Watts | We need 2 such bitmaps. | 18:00.56 |
| so that's 8 Meg gone instantly. | 18:01.06 |
| We then store 3 pages, so that's 24 Meg... | 18:01.30 |
| so, yes, I reckon that's the problem. | 18:01.47 |
Nathaniel7687 | but I use MuPDF Application is not appear this message. | 18:03.41 |
| *When I use MuPDF Application, is not appear this message. | 18:04.07 |
Robin_Watts | Where are you getting that version? | 18:06.45 |
| From the appstore? Or building from vanilla sources? | 18:06.56 |
Nathaniel7687 | both appstore and building from vanilla sources | 18:19.50 |
Robin_Watts | Ok, so it must be something you've changed then. | 18:22.59 |
| It's possible that putting your PDF file in as an asset is costing more memory. | 18:23.24 |
| the jar will be bigger, and it's possible that the runtime has to decompress the PDF file into a buffer. | 18:23.53 |
| I'd run the vanilla source version and look at how much memory you have free. | 18:24.13 |
Nathaniel7687 | oh sorry | 18:25.58 |
| what is vanilla source? | 18:26.06 |
Robin_Watts | vanilla source = unchanged source. | 18:26.23 |
Nathaniel7687 | ah | 18:26.35 |
| I tried to build "http://mupdf.com/downloads/mupdf-1.8-source.tar.gz" | 18:26.51 |
| ah! | 18:27.12 |
| do you know that bufferOpen() method have problem? | 18:27.33 |
Robin_Watts | No... | 18:27.43 |
Nathaniel7687 | wait minut | 18:27.53 |
| If you pass the next page so fast after open pdf file with bufferOpen() method, view is crashed and finish. | 18:30.26 |
| every emulator and mobile device also same | 18:31.49 |
Robin_Watts | I'll just repeat that back to check I understood it. | 18:32.39 |
| If I open a PDF file with bufferOpen() and then flip to the next page quickly, the app crashes ? | 18:33.00 |
Nathaniel7687 | yes | 18:33.46 |
| my English is not good... | 18:34.10 |
| lol | 18:34.12 |
Robin_Watts | It's better than any of my foreign languages. | 18:34.28 |
Nathaniel7687 | cool | 18:34.43 |
| If you find this problem, can you send email for me? | 18:37.04 |
Robin_Watts | Nathaniel7687: I'm horribly busy at the moment, and don't have time to spend on this, sadly. | 18:37.49 |
| I'm just having a quick look to see if I can see anything obvious... | 18:37.59 |
Nathaniel7687 | ah It's so afraid. | 18:38.16 |
| okay~ | 18:38.31 |
Robin_Watts | When it crashes, what does logcat say ? | 18:39.01 |
Nathaniel7687 | oh... hm | 18:42.02 |
Robin_Watts | Nathaniel7687: Ah, right. | 18:42.04 |
Nathaniel7687 | you find it? | 18:42.11 |
Robin_Watts | openBuffer DOES hold the entire file uncompressed in memory. | 18:42.20 |
| So using openBuffer might explain running out of memory. | 18:42.54 |
| It's possible the crash is due to a flaw in my jni. I stash env and thiz, and I bet I'm not supposed to. | 18:43.12 |
Nathaniel7687 | thanks ~ answer my questions~ | 18:50.08 |
Robin_Watts | Nathaniel7687: I will try and find time to look at that at some point. Keep checking back here. | 18:50.51 |
Nathaniel7687 | back here is mean IRC? | 18:51.20 |
Robin_Watts | yeah. | 18:51.25 |
Nathaniel7687 | okay, but I don't know how to see IRC log. | 18:52.08 |
Robin_Watts | I mean come back here every now and then and ask me :) | 18:52.41 |
| If nothing else, it will remind me. | 18:52.51 |
Nathaniel7687 | ah okay memory my name ~ | 18:53.16 |
| Nathaniel Jobs | 18:53.19 |
tpruzina | hello, I have this 16M big pdf of study materials that eats away shitton of memory when I open it in mupdf-1.17, gs-9.15. Just holding down PGDN and getting to the end of the document eats away 800M and this number rises by 100M every time I do search ("/") on it. | 22:29.10 |
| is this expected behavior? | 22:29.21 |
| just noticed it after few hours of studying when memory usage rose way past 5G | 22:30.58 |
| Forward 1 day (to 2015/11/20)>>> | |