| | <<<Back 1 day (to 2012/06/01) | 2012/06/02 |
| Raj | Hi | 04:36.24 |
| ghostbot | hey, raj | 04:36.24 |
| Raj | i am in process of developing a pdf viewer for android | 04:36.47 |
| | using mupdf | 04:36.54 |
| | i need to show a embedded youtube video on specific screen | 04:37.15 |
| | i mean on specific image on pdf | 04:37.29 |
| | can any body give me info on this ? | 04:37.43 |
| | Hi All | 04:41.16 |
| Robin_Watts | Raj, hi | 09:14.07 |
| kens | Robin_Watts : there is already a means to tst for high level devices | 09:16.49 |
| | When I removed the ugly hack testing for the device name I implemented as discussed withg Ray and others at the time | 09:17.25 |
| Robin_Watts | kens: go on... | 09:17.26 |
| kens | Its not the way I would have chosen, but its what was settled on. | 09:17.36 |
| Robin_Watts | ah, ok. I haven't committed mine yet. | 09:17.40 |
| | (It's a very small number of changed lines) | 09:17.49 |
| kens | IIRC we test the device properties | 09:17.51 |
| | I've only just read this far in the logs, give me a minute to find the relevant PS code (this is from PS, right ?) | 09:18.31 |
| Robin_Watts | yes. | 09:18.42 |
| kens | I cna't recall what I did exactly (except that I argued against doing it this way and was overruled) | 09:19.21 |
| | Looks like you should do currentdevice and look for the existence of /HighLevelDevice and then being true or false | 09:21.31 |
| | currentdevice 1 dict dup /HighLevelDevice dup put .getdeviceparams | 09:22.44 |
| | dup type /booleantype eq not {cleartomark //true}{3 1 roll cleartomark not}ifelse | 09:22.44 |
| | See gs_setpd.ps where it is used to avoid installing a default halftone for high level devices | 09:23.31 |
| Robin_Watts | My entire implementation is shorter than that :) | 09:23.45 |
| kens | Robin_Watts : I said I didn't like it, but I think that it is better to use the same method throughout | 09:24.04 |
| Robin_Watts | yes. | 09:24.16 |
| | I'll update on monday I guess. | 09:24.27 |
| kens | OK, sorry to be so late wiht my input | 09:24.38 |
| | FWIW you'll find the same construct around a lot of the PDF interpreter files where it tests device capabilities, but used ot test explicitly against the device name. | 09:25.34 |
| | Robin_Watts : your suggestion (reading on in hte logs) Is exactly what I proposed.... | 09:26.33 |
| kens | returns to the hideous PDF fonts mess. | 09:29.10 |
| sebras | I stumbled upon a crash in mupdf/android. I'm unsure if this is a known problem. | 19:24.39 |
| | E/AndroidRuntime(27327): FATAL EXCEPTION: main | 19:24.48 |
| | E/AndroidRuntime(27327): java.lang.IllegalArgumentException: width and height must be > 0 | 19:24.48 |
| | E/AndroidRuntime(27327): at android.graphics.Bitmap.nativeCreate(Native Method) | 19:24.51 |
| | E/AndroidRuntime(27327): at android.graphics.Bitmap.createBitmap(Bitmap.java:695) | 19:24.54 |
| | E/AndroidRuntime(27327): at com.artifex.mupdf.PageView.setPage(PageView.java:143) | 19:24.57 |
| | Maybe this is better researched by paulgardiner (in which case this is for the logs) | 19:25.26 |
| Robin_Watts | sebras: Are you running the latest version? | 23:42.55 |
| | width/height are set to either 0 or -1 (I forget) before the bitmap is created (or something like that). it can be caused by a race condition when shutting down (or something) | 23:43.38 |
| | and I thought we'd tweaked the code to ensure it didn't happen any more. | 23:43.52 |
| | Forward 1 day (to 2012/06/03)>>> | |
IRC Logs