| | <<<Back 1 day (to 2011/10/06) | 2011/10/07 |
| Robin_Watts | How's the holiday? | 00:00.51 |
| | Whereabouts are you staying ? | 00:00.59 |
| mvrhel2 | We are at the Westin Kanapalli | 00:10.39 |
| | just north of Lahaina | 00:10.49 |
| | Robin_Watts: it is a good spot for the kids. 3 pools, a slide, good beach with decent snorkling | 00:12.25 |
| | Some friends with kids are also here which makes it nice | 00:13.05 |
| | unexpectedly ran into them after we got here | 00:13.22 |
| | amazingly the internet is free here. | 00:14.21 |
| Robin_Watts | Right. Lahaina is the place with the huge banyan tree and the submarine, right? | 00:14.38 |
| mvrhel2 | yes | 00:14.41 |
| Robin_Watts | Nice. | 00:14.51 |
| LaoLang_cool | hello, any mailing list for mupdf? Don't know how to get the breaking news about mupdf | 00:46.20 |
| | news from mupdf | 00:58.24 |
| | hi, I got disconnected, anyone has helped me? | 02:35.31 |
| BamJangles | anyone alive, im just curious about device=bitrbg, how many bits is this in ? | 02:43.07 |
| ray_laptop | BamJangles: | 03:53.21 |
| | BamJangles: the 'bitrgb' device (like the monochrome 'bit' device and the cmyk 'bitcmyl' device) default to 1-bit per pixel, but can be modified to have 2, 4, or 8 bits per pixels using -dGrayValues=4 -dGrayValues=16 or -dGrayValues=256 respectively | 03:55.14 |
| | BamJangles: the 'bit***' devices write the raw data (with each line padded to a byte), but with no header, so if you want to open the file using some utility you will need to know the 'width' of the line and the depth. | 04:05.18 |
| | BamJangles: the 'p*mraw' deviices tend to be more useful since many applicatrion can open the output from 'pbmraw' (gray 1-bit per pixel), 'pgmraw' (gray 8-bit per pixel), ppmraw (RGB 24-bit per pixel) and 'pkmraw' (rendered as 4-bit CMYK, but written as ppmraw 24-bit RGB) | 04:08.26 |
| | BamJangles: also there are a few devices that applications struggle with like the 'pamcmyk32' and 'pamcmyk4' devices that write out variations of that are CMYK with either 8-bits per component or 1 bit per component. | 04:10.32 |
| ray_laptop | is fairly sure that BamJangles has gone away | 04:11.39 |
| | but mentioning this stuff doesn't hurt for the increasing number of folks that seem to be on this channel | 04:12.24 |
| BamJangles | im back | 04:35.26 |
| | cool thanks | 04:35.29 |
| | exactly what i wanted to know | 04:35.34 |
| | ok next qestion does the hostpdl cater for all pclxl (PCL6) classes ie class 1.1 through to 3.0 | 04:38.51 |
| | ghostpdl | 04:38.57 |
| | as i have a spool file from a knoicamoniolta 423 series pcl, which spits out @PJL ENTER LANGUAGE = PCLXL ) HP-PCL XL;2;1; and it seems to hit error code 1 | 04:42.33 |
| | at basically the end of the file which is 1b%-12345X@ | 04:45.15 |
| | %-12345X@PJL EOJ | 04:45.50 |
| | %-12345X | 04:45.51 |
| ray_laptop | BamJangles: the "UEL" <esc>%-12345X is an HP defined "logical EOF" (like ^Z on DOS) | 04:47.08 |
| BamJangles | yeah thats what i thought | 04:47.20 |
| | wonder why ghostpdl dosnt like it | 04:47.46 |
| ray_laptop | the '@' is actually part of the PJL for the next job/file. | 04:47.50 |
| | BamJangles: the ENTER LANGUAGE PJL parser may not like the syntax "PCLXL ) HP-PCL XL;2;1;" | 04:48.52 |
| BamJangles | Warning interpreter exited with error code -1 | 04:48.52 |
| | Flushing to end of job | 04:48.53 |
| | file position of error = 13613879 | 04:48.53 |
| | oh ok | 04:49.19 |
| | @PJL ENTER LANGUAGE = PCLXL | 04:49.59 |
| | ) HP-PCL XL;2;1; | 04:49.59 |
| | its on the next line | 04:50.04 |
| | just incase you thought it was a pjl command | 04:50.14 |
| ray_laptop | I'm NOT an expert at the PCL/PXL languages to know if that is a valid PXL or not. | 04:51.02 |
| | I suggest opening a bug and posting the file as an attachment (bugs.ghostscript.com) | 04:51.34 |
| BamJangles | yeah im nearly 99.99% confident it is a correct pjl command, and an appropriate header of a pclxl file | 04:51.50 |
| | ahh | 04:52.02 |
| | kewl | 04:52.04 |
| | ill do that, if i can solve it , i get 1000$, yay | 04:52.27 |
| ray_laptop | BamJangles: only $1000 for customer bugs. $500 for free user bugs we tag as 'bountiable' | 04:53.02 |
| | unless someone else (we don't know about) is paying for bug fixes | 04:53.25 |
| BamJangles | kewl thanks for your help | 04:54.24 |
| | you need a pay rise :) | 04:54.29 |
| ray_laptop | we are sort of lazy at tagging bugs as 'bountaible', but if you think it is a valuable fix, we will probably tag it/ pay it. | 04:54.42 |
| | it doesn't cost us anything to tag bugs as bountiable (our boss pays for them), but we often don't think about tagging them as such. Often customer bugs have "private" attachments, so there is not much point since they can't access the file | 04:56.26 |
| BamJangles | ahhh ok | 04:57.06 |
| ray_laptop | if you have a bug and a fix, you can always post a comment in the bug that "can I get the bounty for this". Doesn't hurt to ask :-) | 04:58.16 |
| BamJangles | great thanks | 04:59.37 |
| | ill check out the bug site | 04:59.48 |
| ray_laptop | ok | 05:00.00 |
| BamJangles | ill also step through the code and see if i can see whats goign on, basically i wrote my own pcl parser, to count pages of color and black and write, except ghostpcl is like a factor of 10 faster, and more relibale, however the code is about 1000 times more complicated | 05:01.23 |
| | white even | 05:01.39 |
| ray_laptop | BamJangles: the issue with PCL is that "naked" text has line wrap options and page counting is TOTALLY unrealiable without taking into account where the line and page end will happen for a given font and font size | 05:13.19 |
| | PCL is _not_ a simple language to parse for either page counting or text extracrion (in the general case) | 05:14.18 |
| BamJangles | yeah it is a nightmare | 05:14.28 |
| ray_laptop | luckily, I don't have to mess with PCL/PXL so I don't have nightmares ;-) | 05:15.05 |
| BamJangles | hah | 05:15.21 |
| | yeah we primarly do pcl6, and i spent a great deal of time writing parsers for pcl5 and pclxl, however i think ghostpdl might be the way to go, though its extreamly expensive | 05:16.56 |
| ray_laptop | henrys is our expert on PCL/PXL/PJL but he is on holiday until Tuesday PM | 05:16.56 |
| BamJangles | hopefully the bug i found is more a problem with a stupid driver and not somethign that might hold us up, as i see great benifits in dropp our own parser | 05:17.21 |
| | ahh kewl, yeah its friday here, so i might have a chat to him when he gets back | 05:17.38 |
| | dropping | 05:17.48 |
| ray_laptop | BamJangles: Ghostpdl is GPL _if_ you are GPL conformant | 05:17.58 |
| | it's only if you don't want to do a GPL application that GhostPDL (PCL/PS/PDF/XPS) requires a license from us (Artifex) | 05:19.03 |
| BamJangles | yeah im not sure we are, we sell expense managment software to large orgs, though maybe if we made are parsing module gpl compliant it might get us past the licencing component | 05:19.09 |
| | im not sure if that is how it works | 05:19.15 |
| ray_laptop | is not a legal expert either | 05:19.31 |
| | but it's worth checking with Scott or Miles (both @artifex.com) to see if they think you are GPL compliant | 05:20.14 |
| BamJangles | ahh ok yeah its probalby worth a hit, would save us 20k per year or so | 05:20.49 |
| ray_laptop | and of course, we aren't too sympathetic to companies that sell their s/w for 10^x $ and object to paying us anything | 05:21.13 |
| BamJangles | heh yeah i woudlnt think so :) | 05:21.38 |
| ray_laptop | e.g. Oracle tells people to download GPL Ghostscript and their s/w has a $250k +++ per year license fee | 05:22.35 |
| | we consider them leaches until they sign up. | 05:23.18 |
| BamJangles | heheh yeah | 05:23.58 |
| | anyway i better go its nearly knock off time here, thanks for all your help | 05:24.12 |
| | im sure ill be back again | 05:24.16 |
| ray_laptop | BamJangles: OK. Stop by any time | 05:26.49 |
| | it's time to sleep here, too (2225 hr) | 05:27.25 |
| BamJangles | eek. i thoguth you must be up late | 05:27.35 |
| | australia its 3:25pm here | 05:27.45 |
| | anyway cya | 05:27.52 |
| ray_laptop | I'm in PDT (for a few more weeks) | 05:27.59 |
| | then we switch to PST | 05:28.15 |
| | I think I have cust 532 working in 'pdfband' mode (where we render band by band from the PDF we load once) in 2-bit halftoning mode. The threshold array vertical offset needed to be adjusted to prevent 'stitch' lines at band boundaries. | 06:01.35 |
| | now they are taliking about their next generation ASIC that is "smarter" | 06:02.30 |
| Robin_Watts | LaoLang_cool: We have a newsletter that goes out to commercial customers (or potential ones) that includes mupdf news. | 09:29.32 |
| | But nothing otherwise (as far as I know). | 09:29.43 |
| | This is the best place to hang around and ask questions about mupdf though. | 09:29.56 |
| kens | Robin_Watts : do you remember griping about a macro that did a return earlier in the week ? | 09:30.14 |
| Robin_Watts | I do. | 09:30.25 |
| | gs_set_dev_color | 09:30.36 |
| kens | I can't recall, did you have a suggestion for altering it ? | 09:30.37 |
| Robin_Watts | I think it's easy to make it so that the return is explicit. | 09:30.55 |
| kens | I can't use the macro as I need the return value, even when its negative (sepcial case, remap_color) | 09:31.01 |
| Robin_Watts | Let me look | 09:31.29 |
| kens | If you recall the date I can look in the IRC log, I just can't find it off-hand | 09:31.48 |
| Robin_Watts | #define gx_set_dev_color(pgs)\ | 09:32.07 |
| | if ( !color_is_set(gs_currentdevicecolor_inline(pgs)) )\ | 09:32.09 |
| | { int code_dc = gx_remap_color(pgs);\ | 09:32.11 |
| | if ( code_dc != 0 ) return code_dc;\ | 09:32.12 |
| | } | 09:32.15 |
| | That's the current one. | 09:32.16 |
| kens | That's the one | 09:32.19 |
| | remap_color is < 0 so it returns, but I need to know its going to do that. | 09:32.37 |
| | Its pattern colour spaces basically. | 09:32.54 |
| Robin_Watts | #define gx_set_dev_color(pgs) (color_is_set(gs_currentdevicecolor_inline(pgs)) ? 0 : gx_remap_color(pgs)) | 09:33.15 |
| kens | And tehn explicitly test the return value, fair enough | 09:33.40 |
| Robin_Watts | Then instead of calling gx_set_dev_color(x); as we do now... | 09:33.44 |
| | yeah. | 09:33.46 |
| kens | I think I'm going to make the change. I don't like the macro and I need the return value. | 09:33.59 |
| Robin_Watts | That would seem to allow you to do what you want, and it's much cleaner. | 09:34.07 |
| | Fab. | 09:34.12 |
| kens | Fortunately I don't think there are too many cases. | 09:34.19 |
| | The pdfwrite code will be ugly, but that's a consequence of setting Patttern colour spaces in C rather then PostScript. | 09:34.45 |
| | Thanks for the reminder. | 09:35.11 |
| Robin_Watts | np. | 09:51.10 |
| | I see 10 calls. | 09:51.26 |
| Nitesh | HI all | 10:08.33 |
| | I am trying to build mupdf source but getting error /mupdf/android/jni/../../pdf/pdf_cmap_table.c:17: error: 'cmap_7 8_RKSJ_H' undeclared here (not in a function) | 10:09.59 |
| | please help to solve this | 10:10.19 |
| kens | Which OS, compiler, where did you get the source, are you using the included make ? | 10:11.19 |
| tor8 | Nitesh: do you get any other errors or warnings before that? | 10:12.35 |
| Nitesh | Windows XP and get the source from the git | 10:14.16 |
| | No errors before that | 10:14.32 |
| kens | And using which compiler ? Visual Studio ? Which version ? | 10:14.51 |
| tor8 | that's odd | 10:15.01 |
| Nitesh | I am using cygwin to compile | 10:15.20 |
| kens | Right, so not WIndows at all then | 10:15.31 |
| tor8 | kens: I'm guessing the android ndk compiler based on the path? | 10:15.34 |
| | have you built the generated files using a normal (non-android) build first? | 10:16.24 |
| | the message you pasted would make sense if the generated files are missing | 10:16.47 |
| Nitesh | I had followed the README.txt | 10:17.40 |
| Robin_Watts | So you've done step 7 ? | 10:18.14 |
| | and 8. | 10:18.27 |
| Nitesh | and after adding the third party package, i used the ndk-build command and the problem is coming while doing that | 10:18.51 |
| | probably i missed the step 8 | 10:20.16 |
| | there is no generated folder | 10:20.33 |
| | from where i get the generated package | 10:21.09 |
| | ? | 10:21.12 |
| Robin_Watts | 8) Finally, you will need a copy of a 'generated' directory. This is not | 10:21.29 |
| | currently available to download. The easiest way to obtain this is to do | 10:21.31 |
| | a standard windows or linux build of mupdf, which generates the required | 10:21.33 |
| | files as part of the build process. | 10:21.35 |
| | tor8: How would you feel about making a snapshot of the generated stuff available on mupdf.com too ? | 10:22.14 |
| tor8 | Robin_Watts: when we had it there, the statistics showed that pretty much everyone who downloaded the source *also* downloaded the generated stuff even when it was clearly marked as "for cross compiling only!" | 10:23.39 |
| Robin_Watts | tor8: And that's a problem, because ? | 10:23.58 |
| tor8 | so I'd worry that it'd cause more confusion than necessary | 10:24.10 |
| Robin_Watts | Well, if people download it/unpack it when they don't need to, there are no ill effects, right? | 10:24.35 |
| tor8 | there's also the problem with the bundle becoming out of sync with the git | 10:24.36 |
| | which is a larger problem | 10:24.46 |
| Robin_Watts | true. | 10:25.18 |
| kens | Robin_Watts : just starting a cluster test with gx_set_dev_color altered to not return from the macro. It seems OK here but that's with limited testing, and there were a couple of changes required in the PCL code too. | 10:27.41 |
| Robin_Watts | 2 of the 10 were in pcl, IIRC. | 10:28.02 |
| kens | Yes, the rest in the graphics library. I also removed the comment about the return | 10:28.31 |
| | Assuming its OK then I can go on with the pdfwrite code. | 10:29.06 |
| LaoLang_cool | Robin_Watts: commercial customers, so not for normal users? | 10:58.55 |
| | I just want to get the notification to mupdf's new release | 10:59.31 |
| Nitesh | I am still not able to compile | 11:02.29 |
| | it is showing the same message | 11:03.03 |
| | ndk-build not completed and showing the error make: *** [/cygdrive/E/Android/MuPDF/Local-Mupdf/mupdf/and /objs-debug/mupdfcore/../../pdf/pdf_cmap_table.o] Error 1 | 11:03.54 |
| | please help | 11:04.15 |
| Robin_Watts | Nitesh: We'll need to see more context. Pastebin all the output. | 11:04.51 |
| | LaoLang_cool: Not as far as I know. | 11:05.07 |
| LaoLang_cool | Robin_Watts: got it :( | 11:05.30 |
| Nitesh | ror: 'cmap_78_H' undeclared here (not in a function) E:/Android/MuPDF/Local-Mupdf/mupdf/android/jni/../../pdf/pdf_cmap_table.c:17: er ror: 'cmap_78_RKSJ_H' undeclared here (not in a function) E:/Android/MuPDF/Local-Mupdf/mupdf/android/jni/../../pdf/pdf_cmap_table.c:18: er ror: 'cmap_78_RKSJ_V' undeclared here (not in a function) E:/Android/MuPDF/Local-Mupdf/mupdf/android/jni/../../pdf/pdf_cmap_table.c:19: er ror: 'cmap_78_V' unde | 11:06.10 |
| Robin_Watts | Nitesh: No, drop the whole output into pastebin.com | 11:07.47 |
| | and then give us the link. | 11:08.01 |
| Nitesh | http://pastebin.com/JAB4j9fk is the link | 11:12.30 |
| Robin_Watts | OK, now try again with the WHOLE output. | 11:12.54 |
| Nitesh | http://pastebin.com/scsVQY56 is link for whole output | 11:18.29 |
| Robin_Watts | OK, and line 6 should give you a clue as to what is wrong. | 11:19.00 |
| | Do you have a generated directory ? | 11:19.08 |
| | (line 7, sorry) | 11:19.28 |
| Nitesh | From where i can get generated directory or is there any way to generate that? | 11:20.52 |
| Robin_Watts | Step 8 of the instructions. | 11:21.07 |
| Nitesh | I did not understand that. I had downloaded source of the mupdf and third party package | 11:22.24 |
| | please elaborate the step 8 | 11:22.55 |
| Robin_Watts | Normal builds of mupdf involve a step on the host machine where we convert some data (CMAPs, fonts etc) into a more compact form. | 11:23.42 |
| | Unfortunately, the android SDK does not provide a host compiler, only a compiler for the target. | 11:24.02 |
| | Hence we can't perform this step as part of the android build. | 11:24.15 |
| | You therefore need to create the "generated" directory for yourself. | 11:24.36 |
| | This is not available to download. | 11:24.57 |
| | The easiest way to get it generated is to perform a standard windows or linux build. | 11:25.20 |
| | You're using cygwin on windows, so it may be as simple as doing 'make' in the top directory. | 11:26.19 |
| Nitesh | So, should I try to run make on mupdf? | 11:27.39 |
| Robin_Watts | yes. | 11:29.39 |
| Nitesh | Thanks a lot | 11:29.58 |
| | Its working | 11:30.07 |
| | when it was done then i need to run ndk-build | 11:31.01 |
| Robin_Watts | yes. | 11:31.39 |
| Nitesh | there is error in make | 11:32.37 |
| | LINK build/debug/mupdf build/debug/x11_main.o: In function `winopen': /cygdrive/E/Android/MuPDF/Local-Mupdf/mupdf/apps/x11_main.c:125: undefined refer ence to `_XOpenDisplay' | 11:32.44 |
| Robin_Watts | That's fine. You should now have a 'generated' directory ? | 11:33.01 |
| Nitesh | yes | 11:33.35 |
| Robin_Watts | Then your work there is done. Go back to android and run ndk-build. | 11:34.43 |
| Nitesh | I tried but error 1 come | 11:36.48 |
| | Compile thumb : mupdfthirdparty <= jbig2.c In file included from E:/Android/MuPDF/Local-Mupdf/mupdf/android/jni/../../third party/jbig2dec/os_types.h:53, from E:/Android/MuPDF/Local-Mupdf/mupdf/android/jni/../../third party/jbig2dec/jbig2.c:22: E:/Android/android-ndk-r6b/platforms/android-8/arch-arm/usr/include/stdint.h:48: error: redefinition of typedef 'int8_t' | 11:36.54 |
| Robin_Watts | Nitesh: Right, that is a known problem. Hold on a mo. | 11:37.13 |
| | Load thirdparty/jbig2dec/os_types.h into an editor. | 11:44.48 |
| | Change line 43 from: #else | 11:45.56 |
| | to: #elif !defined(HAVE_STDINT_H) | 11:46.07 |
| | and that should solve your problem. | 11:46.13 |
| Nitesh | ok | 11:46.27 |
| Robin_Watts | tor8: I've updated the android ReadMe.txt in my repo on casper. Can you pull that into the main repo please? | 11:48.07 |
| LaoLang_cool | mupdf on android? | 11:48.19 |
| | wow | 11:48.24 |
| Robin_Watts | yes. | 11:48.25 |
| LaoLang_cool | I'm missing mupdf on N900 | 11:48.33 |
| Robin_Watts | mupdf should port to maemo easily enough. It's just linux. | 11:49.08 |
| LaoLang_cool | don't know how usable it is to view pdf on cell phone, how about speed? | 11:49.41 |
| Robin_Watts | LaoLang_cool: Speed is pretty good. | 11:50.01 |
| LaoLang_cool | Robin_Watts: cool! | 11:50.08 |
| tor8 | Robin_Watts: I wonder if we can't fix the jbig2dec header file mess another way | 11:50.11 |
| Robin_Watts | We could fix it in the thirdparty source :) | 11:50.27 |
| LaoLang_cool | I heard that android is a java thing on linux. | 11:50.34 |
| Robin_Watts | as jbig2dec belongs to us, right ? | 11:50.37 |
| | LaoLang_cool: There is a java wrapper that is the app. It calls native code to get to the central mupdf lib. | 11:51.04 |
| tor8 | Robin_Watts: yeah, we can fix the jbig2dec source :) | 11:51.41 |
| LaoLang_cool | most of you use android? | 11:52.14 |
| Robin_Watts | LaoLang_cool: Well, my phone is an android one, if that's what you mean. | 11:54.03 |
| | and I did the android port of mupdf. | 11:54.12 |
| | but most of my time is spent on other operating systems. | 11:54.19 |
| Nitesh | Thanks a lot Robin.. Its done. | 11:56.05 |
| LaoLang_cool | Robin_Watts: I got it. hope some dev can use maemo, so a maemo port would be ready for us too ;p | 11:56.07 |
| Robin_Watts | Maemo died to make way for Moblin which died to make way for LiMo.... | 11:56.49 |
| | Is that a QT based platform ? | 11:56.56 |
| LaoLang_cool | seems that, maemo is based on gtk, meego is based on qt | 11:57.31 |
| Robin_Watts | I have a friend who might be interested in porting mupdf to qt... | 11:57.31 |
| LaoLang_cool | good news! | 11:57.46 |
| | but isn't mupdf based on xlib, why qt? | 11:58.10 |
| Robin_Watts | mupdf is agnostic. The lib dependencies are all in the app layer. | 12:02.43 |
| LaoLang_cool | agnostic, good word | 12:03.42 |
| kens | tor8 someone on stack overflow asking about extracting ToUnicode CMaps from a PDF using MuPDF, can that be done ? | 12:29.04 |
| tor8 | kens: pdfshow can do it, if he knows the object numbers (or can script it to extract the object numbers) | 12:44.14 |
| kens | Don't know about that tor8, just a moment | 12:54.26 |
| | Hmm, he doesn't say, but he *does* say he's extracting the fonts, so I guess the font dict will contin the ToUnicode CMap objetc number | 12:55.12 |
| | http://stackoverflow.com/questions/7681378/extracting-tounicode-tables-from-pdf | 12:55.27 |
| tor8 | kens: there's no magic /Type/ToUnicode marker in the tounicode object | 12:55.36 |
| kens | If you don't want to post an answer I can do it for you, if you tell me how to do this ;-) | 12:55.45 |
| tor8 | but it shouldn't be too hard to adjust pdfextract to look for ToUnicode references for the fonts it extracts and dump those streams too | 12:56.08 |
| kens | tor8 but there a /ToUnicode in the font descriptor isn't there ? | 12:56.09 |
| | OK, can you tell me where to look ? | 12:56.30 |
| | Hmm, I don't actually have a copy of the MuPDF source to hand | 12:57.13 |
| tor8 | pdfextract.c: isfontdesc() looks for a font descripton, then savefont() takes the font descriptor dict and looks for the /FontFileX stream and dumps that to disk | 12:57.34 |
| | I think the ToUnicode is part of the font, not the fontdescriptor, though | 12:57.44 |
| kens | Could be, I always have to check the docs. | 12:57.56 |
| | What's hte URL for MuPDF using Git ? | 12:58.03 |
| tor8 | I just checked the docs :) | 12:58.06 |
| kens | OK fair enough | 12:58.11 |
| tor8 | http://git.ghostscript.com/?p=mupdf.git;a=summary | 12:58.27 |
| | http://git.ghostscript.com/?p=mupdf.git;a=blob;f=apps/pdfextract.c | 12:58.44 |
| | I just do a linear scan of all objects in pdfextract, and save the ones that look like images and fonts | 12:59.07 |
| kens | Cna't I just clone the Git repo ? | 12:59.14 |
| tor8 | yeah, it's the same as the ghostpdl.git just called mupdf.git instead | 12:59.35 |
| | s/the same/in the same place/ | 12:59.43 |
| kens | OK I'll do that, thanks | 12:59.45 |
| | Hmm 'the remote end hung up unexpectedly' | 13:04.17 |
| | Maybe I have the URL wrong | 13:04.46 |
| | mupdf.git is all lower case ? | 13:05.27 |
| | OK, username problem. Fixed now | 13:06.17 |
| | Looks easy enough, I wrote some outline code and posted it. But I bet he's a non-programmer :-) | 13:21.17 |
| | oh goody, e_Remap_Color is not equal to gs_error_Remap_Color.... | 13:24.40 |
| | It looks like someone got it wrong, or one of them was moved.... | 13:29.25 |
| | gs_error_Remap_Color is defined as -107, e_RemapColor is -103. There is no error in ierror.h with the value -107, and gserrors.h only contains one value below -99, which is the remap color one. I cna't see any reason why they are not the same, all the other errors in common have the same value. | 13:32.59 |
| | So lets see what happens if I make them the same :-) | 13:33.41 |
| | Though I do wonder why we have two files with error codes in them, looks like an invitation for this sort of problem. | 13:34.55 |
| chrisl | kens: interpreter errors and graphics library errors - apparently they should be separate <shrug>........... | 13:38.15 |
| Robin_Watts | chrisl: One should be a subset of the other, possibly... | 13:38.52 |
| chrisl | Robin_Watts: personally, I think they should be all one, but it seems that discussion happened long ago | 13:39.33 |
| tor8 | kens: thanks for answering | 13:42.58 |
| kens | One is a subset of the other, except for the one error code which is different.... | 13:45.01 |
| | tor8 no problem. | 13:45.11 |
| | I think the different value is a mistake. | 13:45.51 |
| marcosw_ | can I ask a dumb question about building the windows version of Ghostscript? Why is msvc32.mak the same as msvc64.mak? | 14:13.26 |
| Robin_Watts | It was intended that msvc64.mak should set the appropriate flags and call msvc.mak | 14:14.36 |
| | Why doesn't it? Ask ray :) | 14:15.06 |
| chrisl | And I never use it, so I never noticed...... | 14:15.19 |
| Robin_Watts | I fear it's an oversight. | 14:15.29 |
| marcosw_ | thanks. so nmake -f psci\msvc.mak WIN64= is the correct command? | 14:16.04 |
| Robin_Watts | sounds plausible. | 14:16.20 |
| | marcosw_: Do you happen to know what motherboard you used in miles etc? | 14:16.43 |
| chrisl | I *think* it needs to be WIN64=1 - I think "WIN64=" "sets" it to unset - if you see what I mean | 14:16.59 |
| Robin_Watts | I'm pondering updating my desktop. The 4 gig limit is really getting to me. | 14:17.15 |
| marcosw_ | Robin_Watts: I can probably find out, I think I bought it from newegg, hold on⦠| 14:17.35 |
| | chrisl: neither WIN64= or WIN64=1 work for me, I'll post the error if I can figure out how to cut and paste from vmware | 14:18.33 |
| chrisl | marcosw_: and you can only build 64 bit GS on 64 bit Windows, and then you need to specify BUILD_SYSTEM=64 | 14:19.33 |
| marcosw_ | chrisl: oh, never mind me sending you the error message then. | 14:20.44 |
| | can you build a copy of gs64 for a customer with a patch? | 14:21.01 |
| chrisl | marcosw_: sure, just let me have the details | 14:21.42 |
| marcosw_ | chrisl: I need gs9.04 plus the patch from commit 48e7b9e6aaf93eded227a089b94f90db209476ff | 14:24.20 |
| chrisl | marcosw_: okay, will do it a few minutes....... | 14:25.07 |
| marcosw_ | thx. I should probably install a 64 bit windows. | 14:26.49 |
| chrisl | Doesn't matter how many bits it's got, it's still Windows..... :-; | 14:27.30 |
| | Hmm, that should have been ;-) | 14:27.47 |
| | marcosw_: can you just confirm, that's the fix for Bug 692378? | 14:28.48 |
| marcosw_ | that's the one. it's a three line change. | 14:29.41 |
| | gx_color_value solid_color = gx_max_color_value; | 14:30.04 |
| | is moved into the loop | 14:30.04 |
| chrisl | Yes, looks very innocuous.... | 14:30.13 |
| Robin_Watts | marcosw_: That is causing a problem ? | 14:30.47 |
| | oh, right, sorry, you want to pull that fix in, not exclude it. | 14:32.02 |
| | This is wierd. The following command: | 14:32.50 |
| LaoLang_cool | that's the timeline for mupdf 0.10? :) | 14:33.04 |
| Robin_Watts | gs/debugbin/gs -sOutputFile=ref.pam -dMaxBitmap=10000 -sDEVICE=pamcmyk4 -r300 -dNOPAUSE -dBATCH -K1000000 -sDEFAULTPAPERSIZE=a4 012-09.ps | 14:33.24 |
| | on 64bit linux, causes tile_by_steps to be called: | 14:33.49 |
| | tile_by_steps x0=83 y0=64 w0=42 h0=1 px=0 py=2564 | 14:34.04 |
| | tile_by_steps x0=83 y0=64 w0=42 h0=43 px=0 py=2564 | 14:34.06 |
| | tile_by_steps x0=83 y0=106 w0=42 h0=1 px=0 py=2564 | 14:34.08 |
| | but on 32bit windows, causes tile_by_steps to be called: | 14:34.19 |
| | tile_by_steps x0=83 y0=56 w0=42 h0=1 px=0 py=2572 | 14:34.32 |
| | tile_by_steps x0=83 y0=56 w0=42 h0=43 px=0 py=2572 | 14:34.34 |
| | tile_by_steps x0=83 y0=98 w0=42 h0=1 px=0 py=2572 | 14:34.35 |
| LaoLang_cool | s/that/what/... | 14:34.43 |
| Robin_Watts | LaoLang_cool: We try to release mupdf in line with gs. | 14:35.15 |
| | So August and Febrary. | 14:35.22 |
| | So if all goes to plan, Feb should be 1.0 | 14:35.40 |
| | BUT... it might be 0.95 :) | 14:35.51 |
| LaoLang_cool | Febrary... 4 month remain... | 14:36.23 |
| Robin_Watts | LaoLang_cool: Is there something you feel is missing from the current version? | 14:36.40 |
| LaoLang_cool | Robin_Watts: some minor bug(or called as no friendly feature?) | 14:37.32 |
| | I reported one for hairline width | 14:37.49 |
| Robin_Watts | Have you reported them (or are they in the bug database already) ? | 14:37.56 |
| LaoLang_cool | Robin_Watts: yes, anyway, bed time for me, need to go, see you all :) | 14:38.28 |
| chrisl | marcosw_: Do you only need WIN64, or do you want me to do WIN32 as well? | 14:41.00 |
| marcosw_ | go ahead and build a win32 as well. I already did it and sent it to he customer, but if you build one it might actually be correct. | 14:41.32 |
| chrisl | wouldn't like to bet on that........ but I'll do it | 14:41.59 |
| | marcosw_: the two Windows builds are in my user area on casper - gs904w(32/64)-Bug692378.exe | 14:54.26 |
| | If you could do a quick test of the 32 bit one, to double check I got the patch okay, that'd be great...... | 14:54.57 |
| | Robin_Watts: I think I found the problem on SPARC, and it's not your fault - you're code just handles the problem better | 14:55.42 |
| | The stoopid macros really confused me with their hidden variable use and stuff - the problem turned out to be that the halftoned data stride is not aligned. | 14:57.18 |
| Robin_Watts | Ah. | 14:59.12 |
| | Where is the halftone data coming from? | 14:59.28 |
| kens | There are some indeterminisms which are halftoning, at the moment. 12-07B.ps for one. | 15:00.41 |
| chrisl | It goes back to gxht_thresh_image_init() where penum->line_size and penum->ht_stride get setup and (some of?) the buffers get allocated | 15:00.41 |
| Robin_Watts | And ht_stride is not a multiple of 4 bytes ? | 15:01.21 |
| chrisl | No, it's 45 | 15:01.31 |
| | I'm testing a fix which aligns it to whatever ARCH_ALIGN_MEMORY_MOD - if that works, I'll put up a patch, and assign the bug to Michael | 15:02.47 |
| Robin_Watts | The rest of the code uses 'bitmap_raster' I believe. | 15:03.13 |
| | It's supposed to be independent of ARCH_ALIGN_MEMORY_MOD. | 15:03.39 |
| chrisl | Yes, you're right, I'd forgotten about that | 15:03.55 |
| Robin_Watts | Everything is supposed to use a multiple of 4, I believe. | 15:03.57 |
| chrisl | I'll abort that cluster run, and change it to use bitmap_raster..... | 15:04.58 |
| | Should probably just check that actually fixes the crash before pushing again..... | 15:09.06 |
| chrisl | cranks handle on the SPARC box in vain hope of making it go a bit quicker........ | 15:10.15 |
| Robin_Watts | I started to spec up a replacement desktop box earlier. | 15:10.41 |
| | 800quid for the sandy bridge 6core i7 :( | 15:11.05 |
| chrisl | Mine was ~1200 for a quad core back in January | 15:12.31 |
| Robin_Watts | No, that price was *just* the CPU. | 15:13.17 |
| chrisl | Holy-moly! | 15:14.49 |
| Robin_Watts | There is a new generation of chips (with a new socket) due out in Q4. | 15:15.15 |
| | I hate floating point. | 15:48.54 |
| | You'd think that if you have a double x that when you printf("%g", x); gives you 125, that (int)x would also be 125... | 15:49.33 |
| | I think what I'm seeing here is that banding is different between 32 and 64bit builds. | 15:52.18 |
| | Even with the same parameters set. | 15:52.24 |
| | Presumably somewhere in the calculations we must be taking the size of an array of pointers into account (or something) hence some aspect of banding ends up different. | 15:53.37 |
| | and we get some rounding differences. | 15:55.40 |
| | Morning ray | 17:29.39 |
| | I've got a PCL file here that goes wrong in banding mode. | 17:29.54 |
| | with plank. | 17:29.57 |
| | I'd like to get a list of the rendering operations that are done. | 17:30.11 |
| | I've tried -Zl but it's not quite what I want... | 17:30.42 |
| | is there a better option to try ? | 17:30.47 |
| ray_laptop | What do you mean by 'the rendering operations that are done' ? | 17:31.56 |
| | the -ZL prints more than -Zl and it shows the instructions coming out of the clist as band are rendered | 17:32.36 |
| Robin_Watts | Spot on. | 17:34.23 |
| | Thanks. | 17:34.25 |
| ray_laptop | Robin_Watts: great! glad that's what you wanted. It's rather verbose | 17:34.58 |
| | I showed my lack of knowledge about how JBIG2 files are stored in pdf's :-( I only extracted part of the file. not much surprise that it didn't work. At least I've verified that when I put the Globals part before the other part it works as luratech claims | 17:37.12 |
| | reboot... | 17:49.43 |
| Robin_Watts | Found it. | 20:40.13 |
| | marcosw_: Could you rerun the differences plank vs pamcmyk4 tests for pcl please? | 20:40.37 |
| marcosw_ | will do. | 21:08.12 |
| mvrhel2 | Robin_Watts: you there? | 22:37.04 |
| | so I got a reply back from Marti. Turns out that this is the first profile he has run across with the new floating point extentions | 22:37.28 |
| | extensions | 22:37.32 |
| | he was quite excited to get one. | 22:37.48 |
| Robin_Watts | In case people read logs later: | 23:35.15 |
| | marcosw: Thanks. | 23:35.18 |
| | mvrhel2: Ah, cool! | 23:35.24 |
| | Forward 1 day (to 2011/10/08)>>> | |
IRC Logs