| | <<<Back 1 day (to 2015/07/16) | 20150717 |
| jgcoded | Hi, I'm using the mupdf 1.6 library. I'm trying to load a pdf document that is stored in memory, but I can load the same pdf when I load it as a file. When I try to load the pdf via a stream the program outputs: "error: expected object number" and "error: cannot parse object (4 0 R). I'm actually using another library that wraps around libmupdf. This the their code that opens the pdf document from a stream: http://pastebin.com/ | 04:21.22 |
| | Is that the correct way to load the pdf document from a stream? | 04:21.32 |
| | stream/memory | 04:21.39 |
| | I'm downloading the pdf from the internet and I have it stored in memory | 04:21.53 |
| | What's funny is that if I save the the data I downloaded as a pdf file and use mupdf to open the file using its filename, it opens just fine | 04:23.01 |
| | I am able to get the pdf document file author, creator, etc through code, but it's whenever I try to get a page that I receive those errors | 04:29.49 |
| | my code outputs that there is 1 page, so I try to load page at index 0 and then I get those errors | 04:32.17 |
| | any examples of loading in a pdf file from memory? | 06:40.07 |
| | ah never mind | 06:43.51 |
| | I resolved all of my issues | 06:44.02 |
| sebras | e | 08:17.49 |
| kens | f? | 08:17.57 |
| sebras | ok... that was unnecessary. | 08:17.58 |
| Robin_Watts | g! | 08:22.41 |
| malc_ | bash.org worthy conversation | 09:07.03 |
| Robin_Watts | chrisl: After falling out of the idiot tree yesterday and seemingly hitting every branch on the way down, I seem to have pages being produced with gs inside android mupdf. | 10:28.37 |
| | No fonts though. | 10:28.43 |
| | Line art works. | 10:28.52 |
| kens | is glad it wasn't the subclassing code. Had me worried when I read the logs..... | 10:29.02 |
| Robin_Watts | And I get a single cjkv glyph. | 10:29.19 |
| | which is interesting, cos it's not in the original file :) | 10:30.45 |
| chrisl | That's strange - if it can't find the fonts, I'd expect it to error out] | 10:31.17 |
| Robin_Watts | yeah. | 10:31.36 |
| chrisl | I guess you could try adding -dDisableFAPI to the command line - that might eliminate Freetype as the problem (or not) | 10:32.42 |
| Robin_Watts | Actually, I see some fonts on page 1. | 10:57.19 |
| | but images are missing from there. | 10:58.20 |
| chrisl | I'd be tempted to try to get it run without a clist to eliminate that can of worms | 11:00.10 |
| Robin_Watts | good idea. | 11:01.56 |
| | down to 72dpi should stop clist being used. | 11:02.09 |
| | ok, so tiger.pdf works. | 11:09.43 |
| | no, wait ignore me, it almost works :) | 11:10.16 |
| | I'm screwing up the edge of it on display, but other than that it looks OK. | 11:10.53 |
| chrisl | That's all line work, iirc | 11:11.20 |
| Robin_Watts | yeah. | 11:11.24 |
| | pdf_reference17.pdf doesn't show anything. | 11:11.47 |
| chrisl | So, how about trying "tests/pdf/text_graphic_image.pdf" | 11:14.08 |
| Robin_Watts | will try that in a mo. | 11:15.14 |
| chrisl | Robin_Watts: I think it might be a good idea to hookup stdout and stderr handlers so you can see the backchannel | 11:16.16 |
| Robin_Watts | breakpointing s_process_write_stdout or whatever it was ,worked well. | 11:16.55 |
| chrisl | If you're trying to decipher several lines, that's going to get tedious | 11:17.54 |
| Robin_Watts | chrisl: yeah. I'll look at that in a mo. | 11:18.11 |
| | just trying to fix the edge of tiger, as I think I know what's wrong. | 11:18.22 |
| | OK, tiger (non-clist) works. | 11:19.30 |
| | Let me try tiger (clist). | 11:19.36 |
| | tiger works with clist too. | 11:22.15 |
| | chrisl: OK, what do you reckon the best way to hook stdin/stdout is? | 11:23.44 |
| | There is a mechanism in gsapi for that, right? | 11:23.55 |
| | But AIUI, that only hooks postscript emitted stuff. | 11:24.09 |
| | I guess that's enough for now. | 11:24.28 |
| jogux | robin: freopen stdout/stderr to a file? | 11:25.53 |
| chrisl | gsapi_set_stdio() | 11:30.09 |
| | Robin_Watts: ^^ | 11:30.13 |
| | But jogux's suggestion might be better - do it early, and you'll get output from mupdf, too | 11:31.14 |
| Robin_Watts | jogux: Yeah, to a file is a pain in the ass though. Just awkward to read. | 11:31.51 |
| jogux | robin_watts: adb shell cat foo.txt ? | 11:32.05 |
| | or adb shell cat foo.txt > blah.txt | 11:32.27 |
| | actually there's an adb copy/fetch or whatever, that would make more sense :) | 11:32.54 |
| Robin_Watts | Or... http://stackoverflow.com/questions/10531050/redirect-stdout-to-logcat-in-android-ndk | 11:32.55 |
| | That might get me stdout appearing in the console with no code changes. Let me try that. | 11:33.08 |
| jogux | coo, that's handy. | 11:33.30 |
| Robin_Watts | but doesn't seem to work for me :( | 11:35.29 |
| jogux | is your device rooted? | 11:35.56 |
| Robin_Watts | no. And I don't want to root it either. | 11:36.19 |
| jogux | ah. I bet that's it then. | 11:36.39 |
| Robin_Watts | I can run the shell, and run the commands. | 11:36.46 |
| | When I try to install it seems to add a -Xlog.redirect-stdio option, and that fails. | 11:37.06 |
| | I'll try the freopen this. | 11:37.22 |
| | thing. | 11:37.24 |
| | If I root the phone I can't run my internet banking app, so I'd rather not do that :) | 11:42.10 |
| chrisl | Well, gsapi_set_stdio() *should* get you everything from Ghostscript (but you might miss some stuff from third party libs) | 11:43.40 |
| Robin_Watts | chrisl: Does it get the dlprintf stuff too? | 11:45.58 |
| | I guess it should | 11:46.40 |
| chrisl | I believe so, yes | 11:46.49 |
| | Robin_Watts: I take it you are only running PDFs? | 11:49.29 |
| Robin_Watts | yeah | 11:49.39 |
| chrisl | So you should probably (for now) also use -dPDFSTOPONERROR | 11:50.05 |
| Robin_Watts | http://pastebin.com/pnxHhQ8Q | 11:50.56 |
| | It's run page 1 and page 2 (2 separate runs) | 11:51.09 |
| | No obvious errors or warnings there. | 11:51.23 |
| chrisl | No, that is odd | 11:52.00 |
| | I'm tempted to suggest using a known broken file, and check you get the expected warnings from it | 11:53.11 |
| Robin_Watts | I've pulled back the rendered gprf file, and it looks strange. I suspect the fault lies in my device rather than anywhere else. | 12:04.46 |
| | All the offsets seem to have the top 8 bytes 0. | 12:05.30 |
| | top 6 bytes of 8, zero, sorry. | 12:05.42 |
| chrisl | Well, it can't be endian..... did you use longs? | 12:06.29 |
| Robin_Watts | no. | 12:06.45 |
| chrisl | what about adding in maybe ppraw and checking that works? | 12:07.26 |
| | Or even just the bit device(s) | 12:07.40 |
| Robin_Watts | chrisl: Yeah. | 12:10.26 |
| | Gah. I can't understand the values from the gproof device on windows, and it's WORKING there :) | 12:14.41 |
| | oh, ffs. stupid emacs hexl-mode is confusing me. | 12:29.38 |
| malc_ | Robin_Watts_: there are better hex editors out there... | 12:37.11 |
| kens | chrisl Robin_Watts do either of you know anything about the clip intersection code in Ghostscript ? | 12:39.47 |
| Robin_Watts | malc_: Yeah, but !Zap isn't available on any modern OS :) | 12:39.52 |
| | kens: A bit. | 12:39.56 |
| kens | I've got a weird problem, I have a PS file with 2 clips one after another. Neither is a rectanlge, thery are rhomboids I thnk | 12:40.28 |
| malc_ | Robin_Watts: mcview is okay for light hex viewing/editing.. on windows far | 12:40.29 |
| kens | When I execute cpath_is_rectangle() it comes back saying the current clip is are a rectangle | 12:41.20 |
| | If I write that rectanlge, the clip is incorrect. If I instead write the two clip paths then the result is correct. | 12:41.46 |
| Robin_Watts | kens: That sounds like a bug. | 12:41.58 |
| kens | I would thnk so, but I'm not certain | 12:42.22 |
| | THe inner box of the clip is the same as hte bbox of the path, and the apth is not valid (because its a cli list created by the intersection of 2 paths), so we decide that its a rectangle, whch feels correct. | 12:43.22 |
| | But the numbers in the rectangles look wrong. Like they were reounded up to an int | 12:43.43 |
| | Err I should say the numbers in the bbox'es | 12:44.09 |
| Robin_Watts | The inner bbox of the clip should NOT be the same as the bbox of the path, should it ? | 12:44.22 |
| kens | If its a rectnagle, sure | 12:44.31 |
| Robin_Watts | But for the original clipping paths ? | 12:44.44 |
| kens | Neither path is a rectnagle | 12:44.53 |
| | But its conceivable the result is, I'll need to check | 12:45.02 |
| kens | goes off to draw some pictures | 12:45.13 |
| Robin_Watts | chrisl: OK, ppmraw is giving me the same blank results. | 12:52.38 |
| chrisl | :-( | 12:53.33 |
| | Robin_Watts: So, do you have a page of pure text that shows the problem? | 12:56.03 |
| kens | OK I don't believe either of these clips is rectangular, and I don't believe the intersection is either. BUT it might just depend on the resolution because we actually execute a fill to figure out the rectangle list. Potentially if I change the resolution ths will alter...... | 12:56.32 |
| Robin_Watts | chrisl: Page 1 of pdf_reference17.pdf | 12:56.34 |
| | Let me try cutting that down to a 1 page file. | 12:56.43 |
| | OK, even a 1 page file comes out blank. | 13:06.01 |
| | And all the fonts are embedded, I believe. | 13:06.07 |
| chrisl | OKay, break point in gs_fapi_finish_render() and see what's happening in there | 13:06.29 |
| Robin_Watts | ok, I am there. | 13:07.23 |
| | I see the data is "PDF Ref" | 13:07.44 |
| | and we get a raster, not an outline. | 13:08.27 |
| chrisl | Does the raster have meaningful values in it? | 13:08.42 |
| Robin_Watts | and we're using the gs cache. | 13:08.44 |
| | rast.width = 0 | 13:09.07 |
| chrisl | That's bad..... | 13:09.25 |
| | I guess I should run it here..... it might be a notdef glyph | 13:10.21 |
| Robin_Watts | gs_fapi_ft_get_char_raster has s->bitmap_glyph as a whole bunch of 0's. | 13:10.36 |
| | but advance.x is non-zero, and so is the library pointer. | 13:11.03 |
| | Is there an earlier place I can breakpoint? | 13:11.31 |
| chrisl | gs_fapi_do_char | 13:11.44 |
| Robin_Watts | I'm going to grab some lunch, but will step through that afterwards. Thanks! | 13:12.14 |
| chrisl | at 72dpi, the first glyph width x height should be 22 x 33 | 13:13.54 |
| Robin_Watts | chrisl: OK. I'm in 'load_glyph' in fapi_ft.c | 13:57.22 |
| | and it's calling FT_Load_Glyph with index = 0. That's gonna be bad, right? | 13:57.36 |
| kens | sounds like a notdef | 13:58.00 |
| Robin_Watts | I could run Chrome Remote Desktop here, and let chris poke at the debug if he wants. | 13:59.14 |
| | gs_fapi_do_char. gs_glyph index = 80 on entry. | 14:00.41 |
| | That's P I suspect. | 14:00.54 |
| | chr = 80 too. | 14:01.07 |
| | (I notice in passing that gxfapi.c has lots of code = foo(); code = bar(); code = baz(); with no intermediate checking of code. | 14:03.54 |
| kens | probably to silence compiler | 14:04.30 |
| Robin_Watts | possibly. Though I prefer (void) for that. | 14:05.05 |
| | but that's as may be. | 14:05.19 |
| | I have a font_scale with an HWResolution of 19660800. | 14:06.04 |
| chrisl | These are Type 1 fonts, so we don't use the character code, we use a glyph name | 14:06.18 |
| | What resolution are you running at? | 14:07.37 |
| Robin_Watts | 300, so that makes sense. | 14:09.02 |
| | is_type1 = 1 | 14:10.07 |
| chrisl | I just said that..... | 14:10.21 |
| Robin_Watts | You did, sorry, was just burbling results as I passed them as I step through. | 14:11.08 |
| | I'm back to the call to FT_Load_Glyph now. | 14:11.21 |
| | index = 0. load_flags = 0x300a | 14:11.48 |
| | So how does it know what glyph to load? | 14:11.56 |
| chrisl | I just said that.....^^^^ | 14:12.08 |
| Robin_Watts | You said it uses a glyph name, but I can't see where that is passed. | 14:12.43 |
| chrisl | Put a breakpoint in get_fapi_glyph_data() | 14:12.52 |
| Robin_Watts | Is that pickled into the ft_face already? | 14:13.01 |
| chrisl | It's stored somewhere in there | 14:13.33 |
| | it's in gs_fapi_font.char_data | 14:15.32 |
| Robin_Watts | FT_Outline_Get_CBox is returning me a 0 sized box. | 14:16.07 |
| chrisl | I'd expect so since the bitmap is zero sized | 14:16.50 |
| Robin_Watts | I think the bitmap is 0 sized because that's returning 0, not the other way around. | 14:17.35 |
| chrisl | Right, so what happened in get_fapi_glyph_data() ? | 14:18.23 |
| Robin_Watts | Haven't hit that yet. | 14:18.31 |
| | I may need to rerun if it gets hit before this function is called. | 14:18.43 |
| chrisl | You should have, if you haven been through, you don't have a charstring | 14:19.03 |
| Robin_Watts | OK, that's never being hit. | 14:19.25 |
| | Would you like to share my screen as I debug? | 14:20.21 |
| chrisl | I don't know if I can..... | 14:20.40 |
| Robin_Watts | Do you have Chrome installed? | 14:20.47 |
| chrisl | Yeh, I do | 14:20.57 |
| | Actually, I hace chromium | 14:21.09 |
| Robin_Watts | Install 'Chrome Remote Desktop' extension. | 14:21.10 |
| | That should be fine. | 14:21.30 |
| chrisl | Okay, it's installed, and apparently to control *EVERYTHING* | 14:23.24 |
| | BTW, this is a Type 1C font, so it's effectively CFF...... | 14:24.16 |
| Robin_Watts | I'll give you code via PM. | 14:24.38 |
| henrys | mvrhel_laptop: welcome back | 14:28.42 |
| marcosw | chrisl: I haven't had a chance to work on the cluster code for the build_consolidation branch. I expect to have time this weekend, so hopefully will have something by monday | 14:32.46 |
| chrisl | marcosw: okay. I haven't changed anything of significance to you except fixing that distillerparams issue you found | 14:33.58 |
| | Mostly it's been arsing around with windows stuff | 14:34.17 |
| henrys | marcosw: after customers that is the priority, we want to beat on this as much as possible before release | 14:39.00 |
| chrisl | Robin_Watts: I bet I know what the issue is...... | 14:48.43 |
| marcosw | henrys: understood. | 14:57.21 |
| Robin_Watts | chrisl: ooh, go on... | 15:00.54 |
| chrisl | Freetype - it's in both gs and mupdf, and probably different versions | 15:01.15 |
| Robin_Watts | chrisl: AH! | 15:01.26 |
| chrisl | I'm a little surprised you didn't get a linker error | 15:01.33 |
| Robin_Watts | Hmm. | 15:02.25 |
| | Years ago, on RISC OS I had a tool that would allow me to globally rename/hide functions within a lib. | 15:03.12 |
| chrisl | So, I would guess if you set SHARE_FT=1 and set FT_CFLAGS=-I<path to mupdf thirdparty>/freetype/include it might help | 15:03.21 |
| Robin_Watts | chrisl: Ah, cunning. Will try. | 15:03.36 |
| chrisl | (because I'm assuming that will be easier than trying to make mupdf use the freetype objects gs builds.......) | 15:04.34 |
| | Robin_Watts: Then there will be similar issues with jbig2dec, jpeg, openjpeg (which might explain missing images) and zlib - openjpeg in particular probably harder to resolve | 15:07.05 |
| Robin_Watts | chrisl: I was considering some macro hackery to change the name of freetype entrypoints etc. | 15:07.23 |
| | ISTR that jpeg already has something like that. | 15:07.36 |
| chrisl | Robin_Watts: You need to rename every non-static function, not just the defined entrypoints - could get messy | 15:08.18 |
| Robin_Watts | chrisl: yeah :( | 15:08.50 |
| chrisl | jpeg, jbig2dec and zlib may be less of an issue if both mupdf and gs use the same version | 15:09.30 |
| | Robin_Watts: For jpeg, jbig2dec and zlib, the same trick as I suggested for freetype would probably work. openjpeg I am less sure about, since we don't actually support linking to a shared openjpeg (even unofficially) | 15:12.05 |
| Robin_Watts | Damn, that didn't seem to help. | 15:14.44 |
| | Let me try that again just in case I screwed something up. | 15:15.02 |
| | chrisl: There is a SHARE_JPX flag. | 15:16.34 |
| chrisl | Robin_Watts: Yeh, but that doesn't apply to openjpeg | 15:16.55 |
| Robin_Watts | So, I've set SHARE_JPEG=1 | 15:22.43 |
| | I've changed JSRCDIR from jpeg to ../../mupdf.git/thirdparty/jpeg | 15:23.14 |
| | and it fails to find jpeglib.h | 15:24.01 |
| | I guess I need to add some -I stuff somewhere? | 15:24.49 |
| chrisl | Try adding it to the overall CFLAGS for the whole build | 15:25.10 |
| Robin_Watts | Adding it in GCFLAGS finds jpeglib.h, but then fails to find jconfig.h | 15:25.43 |
| | Is there ordering gubbins with -I stuff? | 15:26.06 |
| | files found in earlier search paths can't include from later ones? | 15:26.24 |
| chrisl | Yes, but it shouldn't really matter | 15:26.37 |
| Robin_Watts | -I./obj is after -I.....jpeg | 15:27.04 |
| | http://pastebin.com/pwLr2BBR | 15:28.54 |
| | Ah, that's cos .obj doesn't have jconfig.h | 15:29.52 |
| mvrhel_laptop | good morning. Thanks henrys. Its good to be back. We had some great weather on mt. Rainer | 15:30.04 |
| Robin_Watts | chrisl: Isn't jconfig.h supposed to be generated as part of the build? Or does that not happen for shared stuff? | 15:31.14 |
| chrisl | It should be copied from base, I think | 15:31.57 |
| | Robin_Watts: see lines about 101 in base/jpeg.mak | 15:32.58 |
| Robin_Watts | We use our own jconfig.h and jmorecfg.h iff we aren't sharing the library. | 15:34.31 |
| chrisl | Yeh. Clearly mupdf does something else to get those | 15:34.50 |
| Robin_Watts | yeah. Found it. Ta. | 15:35.56 |
| | The compilation of mkromfs.c is unhappy when SHARE_ZLIB=1 | 15:55.11 |
| | possibly a cross compilation thing? | 15:55.41 |
| chrisl | yeh | 15:55.52 |
| Robin_Watts | I'll add -lz onto the AUXEXTRALIBS | 15:56.44 |
| | Urgh. MuPDF doesn't build compression into zlib or jpeg. Need to hack those build files too. | 16:19.06 |
| fredross-perry | folks, I am out of the office today. | 16:20.15 |
| Robin_Watts | chrisl: When linux links, it has a rule that no lib can use anything that is in an earlier library, right? | 16:34.02 |
| chrisl | By default, yes, you should get a multiple definitions error | 16:34.31 |
| Robin_Watts | so linking a b c, a can use stuff in b and c, but b and c can never use stuff in a, and c can never use stuff in b. | 16:34.31 |
| chrisl | Sorry wrong end of the stick | 16:34.50 |
| Robin_Watts | And I was linking mupdfcore mupdfthirdparty gs | 16:34.57 |
| | which makes me think we should have been fine. | 16:35.14 |
| chrisl | Maybe - I didn't think ordering was that important these days | 16:35.43 |
| Robin_Watts | cos now when I'm linking "mupdfcore mupdfthirdparty gs", I get told that I'm missing jpeg and zlib entrypoints etc. | 16:35.44 |
| | And when I link "gs mupdfcore mupdfthirdparty", I get told no gsapi_new_instance etc. | 16:36.17 |
| chrisl | ugh, okay :-( | 16:36.45 |
| | Robin_Watts: I can only go back to my original suggestion of using -dDisableFAPI for now, and I'll try to get something I can debug locally next week | 17:05.42 |
| Robin_Watts | chrisl: Don't sweat it. | 17:06.13 |
| henrys | chrisl: so this would be an issue for gsview also if we didn't invoke gs as a process? | 17:06.46 |
| chrisl | I wouldn't have thought so, gsview uses the gs dll | 17:07.12 |
| mvrhel_laptop | windows version uses the api | 17:07.24 |
| | linux version does a process | 17:07.33 |
| chrisl | mvrhel_laptop: yes, but via the DLL, not a static library (windows) | 17:08.26 |
| Robin_Watts | I *could* call as a process, but it involves a horrible hack whereby I have to copy the exe out onto the storage card to call it. | 17:08.28 |
| mvrhel_laptop | yes | 17:08.34 |
| chrisl | Robin_Watts: Is that really an issue for a proof of concept for a show?? | 17:08.59 |
| Robin_Watts | chrisl: possibly not. I can revert to that if I have to. | 17:09.12 |
| | Or I could look at calling gs as a .so | 17:09.29 |
| jogux | Robin_Watts: are you still stuck with unknown symbols? | 17:09.57 |
| Robin_Watts | jogux: only for the last couple of minutes :) | 17:10.20 |
| chrisl | that may not help - .so libraries are less segregated that windows DLLs | 17:10.30 |
| henrys | mvrhel_laptop: I'd like fredross-perry to look at that, using the api, it'd be worthwhile for us to know that kind of thing works okay | 17:10.41 |
| mvrhel_laptop | henrys: yes I agree | 17:11.03 |
| marcosw_ | chrisl: are you still about? | 17:11.05 |
| jogux | Robin_Watts: the 'fix' for unknown symbols due to linker order is adding a bunch of (void)libjpeg_main; or whatever to something that is passed to the linker as a .o file (eg. probably oyur main .c file) | 17:11.06 |
| | ie. make something at the very beginning of the change pull the symbol in and then the -l ordering becomes less relevant. | 17:11.41 |
| | s/change/chain/ | 17:11.46 |
| Robin_Watts | The easy fix is to just mention the libs twice on the linker line :) | 17:11.52 |
| jogux | oh, that works too :-) | 17:11.57 |
| chrisl | marcosw_: for a *very* short time..... | 17:12.13 |
| Robin_Watts | Which is a bit grotty cos I'm using the android 'not makefiles honest'. | 17:12.16 |
| jogux | Robin_Watts: urgh. | 17:12.24 |
| Robin_Watts | but I'll be happy if it works for now. | 17:12.37 |
| fredross-perry | linux and mac versions use gs as a process. | 17:12.44 |
| | what exactly should I look at? I can do it Monday | 17:13.01 |
| henrys | fredross-perry: using the same api mvrhel_laptop uses on windows, not a process | 17:13.32 |
| fredross-perry | oh I see, have the API call gs as a .so? | 17:13.41 |
| | Does the api have progress callback or some other mechanism like it? | 17:14.02 |
| marcosw_ | chrisl: just a quick comment: the binaries for the build_consolidation branch are larger than those for master, gs goes to 30 megs from 24 megs and pcl and xps go to 30 megs from 14 megs. | 17:14.03 |
| chrisl | marcosw_: is that with the *current* code in my repo? | 17:14.37 |
| henrys | fredross-perry: you just need to do whatever mvrhel_laptop did ;-) | 17:14.38 |
| mvrhel_laptop | fredross-perry: you can see how I do the call in ghostscharp.cs | 17:14.40 |
| | oops | 17:14.44 |
| | ghostsharp.cs | 17:14.49 |
| marcosw_ | chrisl: no, let me check with that. | 17:14.59 |
| henrys | mvrhel_laptop: I haven't looked you are depending on check interrupts or anything like that are you? | 17:15.34 |
| | s/are/aren't | 17:15.45 |
| Robin_Watts | WTF. | 17:16.15 |
| mvrhel_laptop | henrys: I am hooked in and monitoring the stdout ad stderr | 17:16.16 |
| | and | 17:16.19 |
| Robin_Watts | W.T.F.F. | 17:16.25 |
| | Why does gs start a jpeg compression thing as it starts up? | 17:16.50 |
| | Something to do with put params in pdf_write. | 17:17.03 |
| mvrhel_laptop | probably the same reason it installs pdfwrite every time | 17:17.06 |
| | hey I was right! | 17:17.17 |
| chrisl | It's pdfwrite - it's part of reading the device params into the Postscript world | 17:17.20 |
| | Robin_Watts: ^^ | 17:17.24 |
| mvrhel_laptop | that really bothers me | 17:17.49 |
| Robin_Watts | me too, but then I don't understand the reason why pdfwrite is 'special'. | 17:18.18 |
| | jpeg is now SEGVing on startup. | 17:19.08 |
| chrisl | marcosw_: actually, scratch that - there's a commit missing. I'll fix it over the weekend....... | 17:19.18 |
| | I *really* have to go now...... | 17:19.25 |
| Robin_Watts | chrisl: Have a good weekend. | 17:19.38 |
| henrys | chrisl: have a good weekend chrisl | 17:19.38 |
| marcosw_ | chrisl: okay, have a good weekend. | 17:19.39 |
| Robin_Watts | So, the basic state of play is that I can build something that works on android for line art. | 17:19.54 |
| chrisl | Thanks all! | 17:19.55 |
| Robin_Watts | For text and images it doesn't work so well. | 17:20.19 |
| | The theory was that this might be to do with shared libs, but I'm not so sure now. | 17:20.36 |
| henrys | Robin_Watts: that's a big step | 17:20.44 |
| | maybe altona doesn't need text ;-) | 17:21.38 |
| Robin_Watts | Ok, let's try the .so way of working. I think that should be safer. | 17:24.50 |
| | Any call made by a function within a .so should only cross out to somewhere else if it's not defined in the .so, I think. | 17:25.21 |
| | So having gs and all its libs in a .so should be self contained enough. | 17:25.38 |
| jogux | Robin_Watts: sounds right to me. | 18:46.58 |
| | Robin_Watts: tbh I think we'd be fine to use so/dlls on iOS (when it comes to that) too. It means we're restricted to iOS 8.0 or higher, but that sounds okay to me. | 18:47.49 |
| | I was tempted to try tweaking the iOS mupdf to using the system libz / libjpeg / etc but never got around to it. | 18:48.37 |
| | I guess possibly we could try that on Android too assuming it has those. Reducing binary size is always good... | 18:50.41 |
| Robin_Watts | yeah. | 18:51.04 |
| | BINGO!!!!! | 19:03.08 |
| | I have the .so version working. | 19:03.13 |
| | And that shows text. | 19:03.17 |
| | I'm missing some graphics from the front of this doc, but they might be in a spot color. | 19:05.19 |
| | which means it might be something in the gs end. | 19:05.31 |
| | And tiger works fine. | 19:10.05 |
| | And images (well, gradients) seem to work too. | 19:14.06 |
| | mvrhel_laptop: So, I think I've got it working. | 19:14.17 |
| | But there are a couple of problems with the gs output. | 19:14.30 |
| | 1) Any spot colors won't be being combined into the rgb at the moment. | 19:14.54 |
| | 2) There don't appear to be equivalent colors for the cmyk. | 19:15.06 |
| | Takes a while to render pages, but it's stonkingly fast when that's done. | 19:15.44 |
| | I'll get that all tidied up on monday and put a version up for people to play with later. | 19:16.10 |
| mvrhel_laptop | Robin_Watts: Awesome | 19:29.12 |
| | I think I am going to rework this one scroll/zoom/tile issue in gsview. the approach I chose is having issues due to when the timing of the ui updates vs my computation of the tile boundaries. instead I will let the ui get its self updated and then I will do the tile. | 19:32.14 |
| | this is only an issue in the zooming case | 19:32.23 |
| | standard scrolling works great | 19:32.31 |
| | lunch time now though | 19:34.27 |
| | yeah! my delayed tile rendering works much better and the code is so much cleaner. | 21:25.58 |
| | grrr that damn 3001 page stress file is giving me some headaches | 21:53.10 |
| | doing some rapid scrolling actually caused a crash in mupdf | 21:53.52 |
| | very odd | 21:53.55 |
| | during the rendering of a display list | 21:54.14 |
| | trying to free a color space... | 21:54.42 |
| | digging further | 21:55.39 |
| | Forward 1 day (to 2015/07/18)>>> | |
IRC Logs