| | <<<Back 1 day (to 2014/09/17) | 2014/09/18 |
| hdon | hi all :) I have a question about programming in ghostscript... can i convert character in a string to its numeric value using ascii encoding? | 06:27.40 |
| | (and vice versa) | 06:28.15 |
| | i can do: GS>StandardEncoding 65 get == and the result is /A | 06:29.25 |
| | and i think that will suffice for the vice versa case | 06:29.37 |
| | i'm thinking that my other option is to create my own dict for reversing this mapping | 06:29.48 |
| | but i also don't know how to convert between nametype and stringtype | 06:30.12 |
| kens | hdon, I think you misunderstand the way text works in PostScript. You can't 'convert a character in a string to its numeric ASCII encoding'. There are no characters in strings, just bytes, depending on the font type one or more bytes constitute a character code. For simple font types character codes are converted to names using the Encoding (which may or may not be StandardEncoding), the name is then used to consult the CharStri | 07:21.27 |
| | ngs dictionary to get the glyph program | 07:21.27 |
| | CIDFonts work differently, these use a CMap instead of an Encoding, but the principle is broadly the same. | 07:21.55 |
| | Acumen Training have a series of technical journals which are very useful: | 07:23.18 |
| | http://www.acumentraining.com/acumenjournal.html | 07:23.19 |
| | See in particular the November and December 2001 issues. | 07:23.38 |
| | Note that you are not programming in 'Ghostscript', the language is called PostScript, and Ghostscript is an interpreter for that programming language | 07:24.12 |
| | And finally, you can use cvn to convert and object to a name, and cvs to convert an object to a string. If you don't already have a copy you need the PostScript Language Reference Manual, which is available somewhere on the Adobe web site, and you should probably also look for the Blue Book and Green Book which I htink are also available there (all in PDF format) | 07:25.33 |
| Kunmyt | hi | 09:40.27 |
| 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. | 09:40.27 |
| Kunmyt | i have problem with mupdf 1.5 build for android, plz help me | 09:40.54 |
| | this is my problem: Exception Ljava/lang/UnsatisfiedLinkError; thrown while initializing Lcom/artifex/mupdfdemo/MuPDFCore; | 09:41.16 |
| tor8 | Kunmyt: are you by any chance using the NDK for 64-bit targets? | 09:42.12 |
| Kunmyt | no | 09:43.00 |
| | before i start it very well | 09:43.19 |
| tor8 | there are two variants of the NDK. one for 32-bit targets, and one for 64-bit targets. | 09:43.54 |
| | there is a problem with the 64-bit target variant, which causes unsatisfied link errors | 09:44.09 |
| Kunmyt | i'm using NDK for 64-bit | 09:44.12 |
| tor8 | we're investigating the issue. | 09:44.30 |
| | you can use NDK for 32-bit until we find the problem | 09:45.13 |
| Robin_Watts | Kunmyt: Can you remember the exact URL of the ndk that you downloaded? | 09:45.14 |
| Kunmyt | i'm download NDK in https://www.google.com.vn/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CB0QFjAA&url=https%3A%2F%2Fdeveloper.android.com%2Ftools%2Fsdk%2Fndk%2F&ei=0qkaVO-rNtD88QWGhYKADw&usg=AFQjCNFwvW32xOi-SNhnfIPC4xkIgTACIA&bvm=bv.75097201,d.dGc | 09:46.03 |
| tor8 | Kunmyt: use one of the Platform (32-bit target) downloads | 09:46.39 |
| | the 64-bit targets have a problem | 09:46.49 |
| | we're trying to find it, but it could take some time | 09:47.01 |
| Kunmyt | ok, i will try with 32-bit | 09:47.07 |
| | tks u very much | 09:47.31 |
| | ah, could you tell me using drawPage to generate Bitmap ? | 09:48.42 |
| Robin_Watts | Kunmyt: The question was which *one* of those URLs you used. | 09:48.52 |
| | I know where to get the ndks from. I don't know which particular version you used. | 09:49.22 |
| | Kunmyt: Could you ask the question more clearly please? | 09:49.39 |
| Kunmyt | i'm sory my bad language | 09:50.04 |
| Robin_Watts | no problem. Your english is better than any of my second languages :) | 09:50.25 |
| Kunmyt | :D | 09:50.37 |
| | i wan't to get Image of first page in pdf file | 09:52.09 |
| | sorry, i want to get Image of first page in pdf file | 09:52.23 |
| Robin_Watts | Kunmyt: OK, that's easy to do. Look at docs/example.c for C code to render pages. | 09:53.13 |
| | Starting from the android viewer source code is probably not the thing to do, cos that's all tied up in specifics for being a viewer. | 09:53.54 |
| | This means you will need to be working at the C level, not the java level. | 09:54.06 |
| Kunmyt | i'm new programer, i don't know that | 09:54.32 |
| Robin_Watts | Then I take it back. It will not be easy to do. | 09:55.01 |
| Kunmyt | You can told me how to do that | 09:55.12 |
| Robin_Watts | I am not going to do lessons in C programming and JNI over irc :/ | 09:56.00 |
| | I'll help with how to call the mupdf API from C, but I'm not getting dragged into more general questions. I just don't have time. Sorry. | 09:57.42 |
| Kunmyt | uhhm, what is the i need to do now | 09:57.45 |
| | ok, | 09:58.14 |
| | first step, i need is ? | 10:01.24 |
| tor8 | Kunmyt: what do you want to do? | 10:01.36 |
| Kunmyt | tor8: I need drawPage first page in pdf file | 10:02.28 |
| tor8 | in Java? | 10:02.36 |
| Kunmyt | in android | 10:02.45 |
| tor8 | in Android you can use native C code, or Java. which one you use is important here. | 10:03.34 |
| | so I'll assume you want to open a PDF file, and draw a page to a bitmap from Java. | 10:04.02 |
| Kunmyt | ok, next step ? | 10:04.29 |
| tor8 | in that case, you'll need to create a Java class that uses JNI to call some C functions that call MuPDF | 10:04.44 |
| | we have something similar to this in our android project, but it is specific to the viewer. it cannot do what you want. | 10:05.16 |
| Kunmyt | thanks you so much | 10:06.03 |
| tor8 | you can start from that and rewrite platform/android/jni/mupdf.c to create your own interface to MuPDF which has a drawPage function | 10:06.04 |
| | in docs/example.c is at example of C code you need to draw a page to a pixmap | 10:06.42 |
| | the platform/android/jni/mupdf.c code is matched with the platform/android/src/com/artifex/mupdfdemo/MuPDFCore.java class | 10:08.26 |
| Kunmyt | i will try use JNI, tks agian! | 10:08.27 |
| tor8 | so you need to rewrite those two files (and delete the other java files) and you can do what you want | 10:08.55 |
| | Robin_Watts: okay, I think I know what's broken with the android 64-bit target ndk | 12:15.27 |
| Robin_Watts | <drumroll> | 12:15.38 |
| tor8 | the libc.so on android devices does *not* have a rand symbol | 12:15.45 |
| Robin_Watts | <cymbal-crash> | 12:15.55 |
| tor8 | the 32-bit target defines rand as a static inline in the header | 12:16.00 |
| jogux | ahhhhh | 12:16.11 |
| tor8 | the 64-bit target declares rand as a plain old function that's supposed to be in the lib | 12:16.14 |
| Robin_Watts | and on 64bit androids, it possibly is. | 12:16.41 |
| tor8 | Robin_Watts: quite. so *unless* you're targeting a 64-bit android, you really must be using the 32-bit NDK | 12:17.02 |
| Robin_Watts | or we could define our own fz_rand ? | 12:17.17 |
| tor8 | which poses a problem, because the L preview only has header files in the 64-bit tarball | 12:17.19 |
| | Robin_Watts: I'm opposed to working around obviously broken C runtimes | 12:17.32 |
| jogux | wait. what. you can build an android app with the 64 bit sdk and it runs on 32 bit devices?! | 12:17.41 |
| tor8 | jogux: yeah.... the 64-bit NDK builds both 32-bit and 64-bit targets | 12:17.57 |
| Robin_Watts | jogux: I think the 64bit stuff is actually... what tor8 said. | 12:18.04 |
| | but the 32bit side of the 64bit support is borked. | 12:18.15 |
| tor8 | but I would not be surprised if the 32-bit targets in the 64-bit target NDK have not been tested at all | 12:18.20 |
| jogux | Ahh. right. | 12:18.32 |
| tor8 | Robin_Watts: I shall update the web page instructions to clarify that you should be using the correct NDK for the target | 12:19.17 |
| jogux | sounds like a mess :-S but at least you got to the bottom of it! | 12:19.18 |
| Robin_Watts | tor8: So, a strongly worded note in platform/android/ReadMe.txt and on the web instructions saying "don't use the 64bit target etc.." | 12:19.22 |
| tor8 | Robin_Watts: yeah. | 12:19.28 |
| Robin_Watts | and say "if you do use it, you will hit this problem... (and maybe others)" | 12:19.50 |
| kens | It would make a nice FAQ entry, if we had an FAQ...... | 12:20.19 |
| jogux | kens: just post it on stackoverflow :-) | 12:20.32 |
| kens | Where everybody will then misunderstand it for the next decade.... | 12:20.50 |
| jogux | if the only problem is rand (I guess that's a big if), it might be easier all round to just workaround it? | 12:22.33 |
| chrisl | Can't we get some we know at google to go round and bang repeatedly on the desk of the personal responsible until it gets fixed?? | 12:23.34 |
| tor8 | jogux: strtof, atof, abs, labs, rand, srand, random, srandom | 12:27.40 |
| Robin_Watts | that we know of, so far. | 12:27.50 |
| tor8 | and who knows what other land mines hide in there | 12:27.51 |
| Robin_Watts | chrisl: s/desk/head/ | 12:28.08 |
| tor8 | just by grepping for static inline in stdlib | 12:28.08 |
| | .h | 12:28.10 |
| Robin_Watts | chrisl: I'm not sure I see Raph in "enforcer" mode. | 12:28.38 |
| chrisl | No, possible not - this is really poor, though. Google are getting to be worse than Apple..... | 12:29.10 |
| | My typing seems to be poor today..... | 12:29.45 |
| jogux | tor8: oh, urgh :-( | 12:33.07 |
| | you could report it in google's bug tracker; there's a very small chance they'd look at it in about 3 years time | 12:33.43 |
| Robin_Watts | "It's been fixed internally, dunno when it will make it to a public release." etc. | 12:34.30 |
| tor8 | Robin_Watts: fixes on tor/master for review | 12:34.32 |
| Robin_Watts | tor8: I reviewed the 26 hours ago ones before, they are all fine. | 12:38.06 |
| tor8 | Robin_Watts: fab, thanks | 12:38.53 |
| Robin_Watts | The external storage crash one seems OK. | 12:38.54 |
| | as long as you've tested what happens when we don't call mPositions.put there. | 12:39.16 |
| tor8 | Robin_Watts: in the absence of external storage, the activity gets put to sleep | 12:39.46 |
| | and then we crash because we don't have an mDirectory | 12:39.54 |
| Robin_Watts | I'd quibble with the text in README. | 12:39.58 |
| | Not all ARMs are 32bit. | 12:40.02 |
| tor8 | Robin_Watts: feel free to rewrite it | 12:40.15 |
| Robin_Watts | If you're targetting a 32-bit platform (such as most ARMs) ? | 12:40.23 |
| | Otherwise it's great. | 12:40.47 |
| tor8 | isn't 64-bit arm called ARM64? | 12:42.09 |
| | I think for our target audience, ARM == 32-bit ARM and if you know better then good for you :) | 12:42.27 |
| Robin_Watts | I think Android devs are frequently morons who will seize on every opportunity to misunderstand stuff. | 12:43.05 |
| | If you're targetting a 32-bit platform (such as all ARMs other than those explicitly described as ARM64) ? | 12:43.45 |
| tor8 | (such as "ARM EABI v7a" or "Intel x86 Atom") then? to mirror the terminology in the android SDK | 12:43.48 |
| Robin_Watts | that assumes that people actually read the sdk. :( | 12:44.28 |
| tor8 | I wonder how to test the 64-bit targets ... I can't find a system image in the android tool | 12:44.33 |
| | "If you're targeting a 32-bit platform (which you are, trust us)." | 12:45.44 |
| Robin_Watts | hehe | 12:46.39 |
| | I'm expected arm64 androids to hit the market before the end of the year, possibly as early as october when L is supposed to ship. | 12:47.27 |
| tor8 | Use the 32-bit target NDK unless you are explicitly targeting a 64-bit platform. | 12:47.34 |
| | no, that implies you can use the 64-bit NDK... | 12:47.55 |
| Robin_Watts | I suspect that most android devs just think "I have a 64bit PC, so..." | 12:48.27 |
| tor8 | Robin_Watts: yeah. most likely they just read "64-bit" and ignore the "target platform" heading | 12:50.13 |
| | the "ARM EABI v7a" wording is used in the "android" tool when you download a system image, so I'm inclined to go with that wording | 12:50.42 |
| Robin_Watts | What's the ARM64 equivalent of that ? | 12:51.03 |
| tor8 | Robin_Watts: dunno, I can't see any other system images :( | 12:51.20 |
| chrisl | It's also called aarch64 in various places..... | 12:52.25 |
| Robin_Watts | is summoned for lunch. | 12:53.32 |
| tor8 | Robin_Watts: and in the AVD manager it's ARM (armeabi) or Intel Atom (x86) | 12:57.26 |
| Robin_Watts | henrys: I think the time for NRE is upon us. | 14:35.40 |
| henrys | Robin_Watts: okay | 14:36.39 |
| | Robin_Watts: I gave miles 2 choices "go away" or very high priced NRE | 14:42.59 |
| kens | Trying to match another application seems daft, especially when the colour conversions will almost certainly be different. | 14:43.30 |
| Robin_Watts | I was tempted to say "at this point, I feel it's incumbent upon you to do some debugging. It should be a simple job for any competent programmer." | 14:44.11 |
| kens | Seesm to me if they like hte other application, and they have it, they should just use it. | 14:44.20 |
| | Robin_Watts : yes...... | 14:44.30 |
| chrisl | Robin_Watts: to which they would say: "Please write us suitably witty retort as we cannot write one ourselves....." | 14:45.56 |
| henrys | Robin_Watts: just don't respond hopefully miles' price will scare them into working more independently. | 14:46.19 |
| | as marcosw would say "sorry you aren't smart enough to be our customer" ... | 14:47.24 |
| rayjj | robin_watts: I must say that you have been much more patient than I would have been. The other issue is that they aren't even our customer, just doing work for a customer. | 14:53.13 |
| | Maybe we should contact cust 535 and tell them of the difficulty we are having supporting their contractor. | 14:53.51 |
| kens | Goodnight all | 16:36.58 |
| norbertj | rayjj: just a question. Do you have any new insights on 694750 , Why (on Winy) NumRenderingThread>3 has no perf improvements? | 17:14.12 |
| rayjj | norbertj: I don't know yet. I've been working on another project, and sort of waiting until after our release (imminent). I am adding per-thread instrumentation to determine where the threads are waiting | 17:17.00 |
| | norbertj: but since some of the "waits" during clist playback for for a variety of mutexes, it is needing some minor surgery to be able to track the thread_id throughout | 17:19.33 |
| norbertj | rayjj: If I can help with this ... | 17:20.45 |
| rayjj | norbertj: your results weren't quite the same as mine. Do you think my results are similar enough to yours ? (you had almost 14 vs < 10 seconds, but I saw some improvement 19.6 down to 18.5 for 4 threads) | 17:30.25 |
| | your 13.37 sec time was for 5 threads, 9.95 for 0 threads | 17:31.10 |
| | but I _do_ see that the CPU % is less than 30% even with NRT=4 | 17:32.01 |
| | norbertj: I have to run an errand and will check back later. Since you mention this, I'll spend some time on it today. My other project is needing some support from vmware | 17:33.52 |
| | (or I have to actually boot into linux :-( ) | 17:34.16 |
| norbertj | rayjj: the 4.42 secs is probably the overhead for clist generation (in memory) en creation of the threads. And I did see no improvements on the 14secs (no matter how many threads I used). I have a quad-core with hyperthread, so 8 'cores' in total.But the CPU usage in taskmanager does not get above 13% (i.e. 1 full core). | 17:34.30 |
| rayjj | I'm tempted to just fire up an old machine with lnux so I don't have to reboot my laptop | 17:35.13 |
| norbertj | rayjj: no problem. I'm at home now, but at work I can also try some investigations (if I knew where to look for ; which mutexes in the clist playback are used). | 17:36.00 |
| rayjj | norbertj: oh, so the 9.95 second was not in clist more ? | 17:36.12 |
| | norbertj: I was focused on clist mode for all timings. it's easy enough to measure clist creation time. | 17:37.44 |
| norbertj | rayjj: no it was without clist (i.e. it is the equivalent to the perf we get in our current pdl-implementation, which due to the pcl-creep-perf was becoming too slow). That's why I was investigating the NumRenderingThread approach. | 17:38.14 |
| rayjj | norbertj: if you could do that and confirm (on bug 695374) that the difference is clist creation time, that would help -- then I can continue to focus on why NRT>0 shows such small improvement | 17:39.00 |
| norbertj | I do remember though that a few years ago I also tried this, and with XP (which was our platform at the time) it only got worse with the number of threads. But with WIN7 then I did get the improvements. But that is not working anymore. | 17:39.10 |
| | rayjj: will do. | 17:39.31 |
| rayjj | norbertj: thanls | 17:39.45 |
| | thanks | 17:40.49 |
| | bbiab | 17:40.58 |
| mvrhel_laptop | bbiab | 18:51.38 |
| | grumble grumble. I have all the mark up correct and the rels stuff all set up and the image in the proper spot. something is not quite right though with my xps file. running it through gxps to see what might be wrong | 21:23.44 |
| | huh. gxps gave me a segv on start up | 21:34.47 |
| | updating and rebuilding... | 21:35.01 |
| | ok false alarm. | 21:47.35 |
| | well that is interesting. AR opens my xps output just ine | 23:27.50 |
| | fine | 23:27.52 |
| | gs draws a blank page and ms complains about the file | 23:28.16 |
| | ah. gs does work | 23:44.30 |
| | Forward 1 day (to 2014/09/19)>>> | |
IRC Logs