| | <<<Back 1 day (to 2013/08/18) | 2013/08/19 |
| abhie | hello everybody....any body can help me please.... | 03:49.20 |
| kens | chrisl ping | 07:54.16 |
| chrisl | kens: pong | 07:59.03 |
| kens | got a build problem bisecting, hoping you can tell me what should be in the makefile.... | 07:59.20 |
| | In lib.mak is: | 07:59.37 |
| | MKROMFS_ZLIB_OBJS=$(MKROMFS_ZLIB_OBJS_$(SHARE_ZLIB)) | 07:59.37 |
| | and nmake barfs on that line (285) | 07:59.51 |
| | Sorry that's line 2815 | 07:59.58 |
| chrisl | What's the commit? | 08:00.18 |
| kens | oine moment | 08:00.25 |
| | 555b185 "Merge of halftone branch..." | 08:00.42 |
| | ops no | 08:01.04 |
| | make that 2a97e79 | 08:01.13 |
| | I read the wrong line | 08:01.20 |
| chrisl | It *seems* to work for me, although I get another build error. Did you rerun autogen.sh? | 08:02.48 |
| kens | This is WIndows... | 08:02.55 |
| | 1>.\base\lib.mak(2815) : fatal error U1001: syntax error : illegal character '$' in macro | 08:03.14 |
| | 1>Stop. | 08:03.14 |
| | I'm assuming nmake doesn't like a macro inside a macro | 08:03.34 |
| chrisl | Yeh, I've hit that before :-( Give me asec | 08:03.58 |
| kens | OK | 08:04.03 |
| chrisl | MKROMFS_ZLIB_OBJS=$(MKROMFS_ZLIB_OBJS_0) | 08:04.43 |
| | Should work | 08:04.46 |
| kens | OK one sec | 08:04.50 |
| | OK that build is running now thanks ! | 08:05.26 |
| chrisl | I then get: 'No rule to make target `base/gsroprun24.h', needed by `obj/gsroprun.o'. Stop.' | 08:05.56 |
| kens | THa'ts not happening for me, at least not yet.... | 08:06.12 |
| | AH "cannot include file zlib.h" | 08:06.40 |
| | while building FreeType | 08:06.53 |
| | I suppose I need to find a commit near that one which will build | 08:07.20 |
| | I'll use skip | 08:07.25 |
| | fingers crossed I don't have to skip many | 08:07.40 |
| chrisl | That's very odd - I really thought we'd been good about only committing stuff that actually builds :-( | 08:09.00 |
| kens | 8.71 was a long time ago | 08:09.16 |
| chrisl | Yes, if you're building Freetype, that's considerably past 8.71 | 08:10.03 |
| kens | I'm in the 9.0 series somewhere | 08:10.16 |
| | between 9.0 and 9.03 | 08:10.25 |
| chrisl | I'm not sure henrys' comment makes total sense on this bug - we switched back to x11alpha once most of the the problems with it were fixed. So presumably x11alpha was *actually* fixed at some point | 08:13.19 |
| kens | I'm guessing he was checking with the default device and his bisect came up with that commit. So he ran out of time to redo the bisect with a different device | 08:14.17 |
| | OK that got me past the build problem, thanks | 08:14.49 |
| chrisl | The implication of the mail was the problem couldn't be tracked down on Linux/Unix/Mac...... | 08:15.48 |
| kens | I assumed he just meant that he would have had to restart bisect with a different device, its easier on Windows because the default device exhibits the bug | 08:16.27 |
| chrisl | I'd rather type the extra -sDEVICE=.... than work in an unfamiliar environment, personally...... | 08:17.52 |
| kens | :-) | 08:18.00 |
| at_earth | Morning All | 08:49.14 |
| | I am starting new with MuPDF and i am lost in the whole world. I was wondering if some one knows or can give me some pointers | 08:51.04 |
| kens | at_earth : You may be just a little early | 08:52.41 |
| | If you can hang around there should be a couple of the developers on here at any time | 08:53.14 |
| | chrisl I finished the bisect, but I' not sure I believe the commit that came out, going to do a little testing | 08:53.42 |
| at_earth | Kens, Thanks. will be around | 08:55.06 |
| Robin_Watts | at_earth: What do you want to know? | 08:56.03 |
| at_earth | Using MuPDF can we convert page into a Image, because i have to draw the image on canvas to add some interactivity. | 08:59.56 |
| Robin_Watts | at_earth: Sure. | 09:00.31 |
| at_earth | thanks robin, any pointers on how to do this would be very very helpful | 09:01.07 |
| Robin_Watts | at_earth: Look at doc/example.c | 09:01.42 |
| | that open a PDF file and renders a page to a bitmap. | 09:01.52 |
| at_earth | thanks will look into that now and come back .. really appreciate | 09:02.19 |
| | one quick question, how will i use that in adnroid? | 09:03.02 |
| | i am incorporating MuPDF in my android app | 09:03.17 |
| Robin_Watts | Ah, well, that's more interesting. | 09:03.22 |
| | The MuPDF API is a C level one. | 09:03.30 |
| | For our example Android app, we've wrapped up some of the C level stuff and made it accessible from java using jni. | 09:04.05 |
| | We haven't wrapped up everything, just what we needed. and we haven't just wrapped up exactly the same API, we bundled some things together. | 09:04.49 |
| at_earth | i am not an expert in C.. | 09:05.12 |
| Robin_Watts | hence you will probably need to do some JNI work yourself. | 09:05.13 |
| at_earth | JNI ? | 09:05.22 |
| Robin_Watts | JNI = Java Native Interface. | 09:05.55 |
| | It's the mechanism by which java can call C functions. | 09:06.09 |
| | You don't need to be an expert at C, but you will need some basic knowledge in that area. | 09:06.46 |
| at_earth | i was hoping to have some straight solution, any other library you can suggest, i just need pdf page to be converted to Image. | 09:06.53 |
| Robin_Watts | at_earth: Not currently, sorry, no. | 09:07.21 |
| at_earth | sure Robin i will give it a try. Thanks | 09:07.36 |
| | i will come back and update you on progress and also ping you if any issues.. Really appreciate | 09:08.11 |
| Robin_Watts | cool. no problem. | 09:08.30 |
| kens | chrisl ping | 09:14.58 |
| chrisl | kens: pong | 09:17.24 |
| kens | chrisl I have a potential fix patch for the customer, but..... I'm unable to test it, because my Windows environment will no longer build a vanilla 8.71. Could you checkout a plain old 8.71 (SHA f41d1fb), apply the patch and quickly test it ? | 09:17.41 |
| chrisl | Sure, np | 09:18.18 |
| kens | OK it not really worth a diff, I'll send you a mail | 09:18.36 |
| chrisl | Can you include the test job? | 09:19.02 |
| kens | Sure | 09:19.08 |
| kens | had forgotten it was a 5MB test file | 09:21.41 |
| | OK mail has gone, may take a minute or two to arrive with such a large attachment | 09:24.09 |
| chrisl | Hmm, 8.71 won't build on Linux either :-( | 09:24.27 |
| kens | Oh dear :-( | 09:24.37 |
| | I was assuming it was just Windows | 09:24.46 |
| chrisl | i get a bunch of errors in tiffio.h | 09:24.58 |
| | Let me try a different gcc version..... | 09:25.51 |
| kens | Ah, I can't compile any C file, which I'm pretty sure is down to the fact that VS 2008 doesn't like something. I guess I could boot up my old PC< its still got all my old setup on it, and it may buil;d | 09:25.54 |
| | Of course first I have to plug keyboards and stuff back into it. | 09:26.27 |
| | I'll start that process now. | 09:26.33 |
| chrisl | kens: don't worry, I'll build without tiff | 09:27.15 |
| kens | OK | 09:27.24 |
| chrisl | Okay, that got vanilla 8.71 building, so now to patch and test..... | 09:29.12 |
| kens | Ah great, thanks! | 09:29.21 |
| | my old PC is still booting up :-) | 09:29.33 |
| chrisl | Any particular command line? | 09:29.51 |
| kens | I just used the default viewer on WIndows | 09:30.15 |
| | Its a rangecheck error, so any device 'should' be OK | 09:30.34 |
| chrisl | Nope, I still get a rangecheck.... | 09:32.18 |
| kens | Hmm, well I guess then that its more than one change that affected it | 09:32.51 |
| | I'm inclined in the direction of 'just upgrade we can't patch this' | 09:33.43 |
| chrisl | Well, you know my feelings on this. Why have spent hours on a *long* deprecated version | 09:34.51 |
| kens | Yes indeed, it was only that i 'looked' like a fairly simple change in PostScript, but since that doesn't work, I think its time to give up. I'll put a mail to tech and support (but not the customer) and Marcos can decide | 09:35.40 |
| | FWIW my old PC seems to be OK building 8.71 under VS 2005 | 09:36.07 |
| | Unfortunately the two can't see each other on the network, and Stella has waled off with my USB drive, so the only way I can copy files between the 2 is via the wider interenet.... | 09:37.33 |
| chrisl | Aha, it seems that 8.71 didn't run the tiff configure script automatically - if I do that manually, it builds fine on Linux. "Obvious" really! | 09:39.10 |
| kens | I guess so :-( | 09:39.25 |
| chrisl | So, did your bisect not narrow it down to a specific commit? | 09:39.57 |
| kens | Yes it did, but the /.execgroup routine was not the same, it had previously been modified | 09:41.46 |
| | WHich was why I hoped simply replacing it whoelsale would work, obviously it doesn't | 09:42.07 |
| | Presumably that means that 'something else' had previously changed which also affects this, and the commit relies on that (probably without realising it) | 09:42.54 |
| chrisl | Well, frankly, that's always an (increasing) risk with such an old version | 09:46.38 |
| kens | Of course! I don't intend to try and track down the other patch, if Marcos feels inclined he can do so, or (my preference) tell the customer they need to upgrade | 09:47.16 |
| Robin_Watts | powers pi up for first time. | 10:14.07 |
| sags | Hi all. It looks to me that "filenameforall" is seriously broken. And as I think a new release is close... | 10:23.32 |
| Robin_Watts | hears a distant explosion from the direction of andover... | 10:24.23 |
| sags | The problems come from commit f13bfba957c536630a241351df49c5007a0664d9. | 10:24.33 |
| kens | sags can you open a bug report please | 10:24.45 |
| at_earth | hello Robin | 10:25.13 |
| | quick summary did not manage to achieve it | 10:25.48 |
| Robin_Watts | at_earth: hi. In general, on irc, and in particular here, while greetings are nice etc, don't wait to get a response before asking questions :) | 10:25.57 |
| | at_earth: ok... | 10:26.11 |
| at_earth | Open Question then :) | 10:26.14 |
| | in the sample of MUPdf | 10:26.39 |
| sags | Difficult to describe a bug when the intended behaviour is unknown. For example, there currently therfe is a known limitation vaguely described as "does not support directory patterns", yet it does recurse (badly) into directories and the wildcards *much* directory names. | 10:27.00 |
| at_earth | instead of getting the PDF getting rendered swipe left and swipe right | 10:27.23 |
| sags | s/much/match/ :) | 10:27.27 |
| at_earth | want it to come in vertically | 10:27.53 |
| kens | sags if you can't describe the behaviour as werong, then I can't see it as a bug ;-) | 10:28.02 |
| at_earth | as in I scroll PDF downwards and apply boxes on it | 10:28.18 |
| | is that possible qith MuPDF | 10:28.40 |
| sags | Well, one consequence is that COMPILE_INITS=0 + GS_LIB using backslashes as directory separators = /undefinedresource in /resourceforr for pretty much everything. A simple "gswin32c -c "{} bind"" shows it. | 10:29.35 |
| kens | SO... don't use backslashes ? | 10:29.56 |
| sags | s/resoureforr/resourceforall/. My typing is very bad. | 10:30.10 |
| | But backslahes are the normal separator on Windows. | 10:30.38 |
| chrisl | sags: does it work if you use "\\" instead? | 10:31.32 |
| kens | But not in PostScript | 10:31.40 |
| sags | Dodn't try, but don't think so. One of the problems is the code after "/* translate the template into a pattern discarding the escape */" (see commit I mentioned) was removed, so template processing is wrong. | 10:33.35 |
| kens | sags, please open a bug, random examples aren't helpful, I'd rather see this written down | 10:34.19 |
| sags | @kens: Not in PS, bug GS_LIB is an environment variable. So, system | 10:34.25 |
| Robin_Watts | at_earth: back. | 10:34.40 |
| | at_earth: So you're dropping back to just using our example Android app. | 10:34.58 |
| sags | Well, I I'll find time I will. If not, it will remain as-is. | 10:35.12 |
| Robin_Watts | The way the pages (views) move is all done in the java code. | 10:35.39 |
| | See platform/android/ClassStructure.txt | 10:36.05 |
| | So if you tweak the appropriate classes you can change it as you describe. | 10:36.33 |
| chrisl | Well, that's *extremely* helpful :-( | 10:36.38 |
| Robin_Watts | chrisl: Doesn't seem clear to me if sags was saying "this used to work and now doesn't" or "I'm trying this for the first time, and it's not working" | 10:39.12 |
| kens | chrisl, yes indeed....# | 10:40.57 |
| Robin_Watts | I've got an email for sags somewhere. Should I send him a mail? | 10:41.33 |
| kens | I could pull it from Bugzilla | 10:42.00 |
| chrisl | I can't seem to get GS_LIB to work at all :-( | 10:46.35 |
| kens | wOn Linux ? | 10:46.45 |
| chrisl | On Windows | 10:48.08 |
| kens | Hmm, well I'll look at that this fternoon,pretty sure the resources hting worked and that was using GS_LIB | 10:49.59 |
| chrisl | kens: it does seem that backslashes used to work on Windows | 10:57.35 |
| kens | Well, I@ll look at it after lunch | 10:57.47 |
| | Anotherr one waiting for the rel=ease to test.... | 10:58.08 |
| chrisl | NP, it was just a bit of a surprise to me, frankly! I thought we always recommended using the PS style separator rather the the platform one...... | 10:58.37 |
| kens | We always do | 10:58.49 |
| Robin_Watts | I wonder if I can set up a VNC server on the pi... | 10:59.29 |
| chrisl | Robin_Watts: sudo apt-get install tightvncserver | 11:10.09 |
| Robin_Watts | chrisl: Yeah. I'm using Xming/putty. | 11:47.13 |
| | just to save me having to keep swapping the monitor/coping with too many keyboard/mice. | 11:47.41 |
| chrisl | Robin_Watts: I think that's probably a better option than vnc. | 11:47.54 |
| | I'd expect X to be better on the network traffic than vnc | 11:48.39 |
| tor7 | chrisl: and on latency | 11:49.51 |
| chrisl | Yes, true | 11:50.11 |
| kens | Hmm, I can't see how changing the WIndows filenameforall prevents GS_LIBform working, but stranger things have happened | 12:04.34 |
| chrisl | kens: GS_LIB works okay, but if you do the gswin32c -c "{} bind" thing sags mentioned, you'll get an error in resourceforall (IIRC) | 12:06.16 |
| kens | will look | 12:06.46 |
| chrisl | Oh, I get /undefinedresource | 12:07.39 |
| kens | Give me a minmute, I'm putting my system back in order after this mornings bisect | 12:08.13 |
| chrisl | Having said that, I couldn't get GS_LIB to work, so I used "-I". | 12:09.07 |
| kens | OK So I have to rebuild with COMPILE_INITS=0, set GS_LIB with backslashes and then run {} bind ? | 12:09.11 |
| | I'll work on GS_LIB first then | 12:09.24 |
| | I'm pretty sure I have a test for that | 12:09.31 |
| chrisl | 4 | 12:12.46 |
| kens | Oh I'm thinking of the relative GenericResourceDir, that won't be any use | 12:13.21 |
| chrisl | I've been try "set GS_LIB=....." then running gswin32c and it still doesn't find gs_init.ps :-( | 12:16.00 |
| kens | I take it this works on Linux ? | 12:16.20 |
| chrisl | Haven't tried it. On Windows I'm trying it with the commit prior to the filenameforall fix | 12:16.58 |
| kens | SO it works before and not after ? | 12:17.13 |
| chrisl | No, I can't get GS_LIB to work at all - but that's probably me | 12:17.37 |
| kens | Well I guess I have to solve that first :-) | 12:17.53 |
| | Where did you put COMPILE_INITS=0 in the project ? | 12:18.09 |
| chrisl | I built on the command line - I almost *never* use the projects | 12:18.36 |
| kens | Ah, this might take some time then | 12:18.55 |
| | First I'mgoing to have to make COMPILE_INITS=0 work, and the experience with UTF8 wasn't good in taht respect | 12:19.19 |
| chrisl | kens: I can get GS_LIB to work on Linux, I guess I'm not setting it correctly on Windows..... | 12:21.43 |
| kens | Hmm, OK | 12:22.04 |
| | I'm rebuilding (again) and setting up windows, I'll have to reboot to set the environment | 12:22.28 |
| chrisl | Hmm, I *thought* used "set GS_LIB=..." was sufficient if you then run the exe in the same command prompt instance..... | 12:23.13 |
| kens | Yes, but I want to use the debugger, which means it has to be system wide | 12:23.36 |
| chrisl | But (based on what sags implied) GS_LIB should work sufficiently well for gs to startup now, and work fully before the filenameforall fix, and I can't get gs to initialise even with the old code | 12:25.54 |
| kens | I can't even tell at the moment if I've managed to build without a rom file system | 12:26.20 |
| chrisl | Look at the build output | 12:26.48 |
| | Oh, balls, I bet it's the UTF8 thing..... | 12:27.23 |
| kens | Well I was wondering that yes | 12:27.34 |
| | WHich is why I want to look at it | 12:27.43 |
| | and also why I wanted a bug report.... | 12:27.55 |
| | OK which makefile are you building form the command line ? | 12:30.03 |
| | ah the one in psi | 12:30.23 |
| | As I thought the command line doesn't work for me. I think the =vcvasrs.bat doesn't se up the path | 12:31.21 |
| chrisl | Use the VS tools command prompt | 12:31.42 |
| kens | I am | 12:31.47 |
| | 'C:\Program' is not recognised as an internal or external filename | 12:32.08 |
| | THe shell didn't handle the space in 'Program Files' properly | 12:32.24 |
| chrisl | nmake psi\msvc32.mak DEVSTUDIO= | 12:32.25 |
| kens | ah OK | 12:32.30 |
| | OK that works thanks | 12:32.43 |
| | Of course, no .sbr files this way but if it actually builds iot properly I guess I'll be happy | 12:33.34 |
| chrisl | In the project, each nmake "target" actually has at least 2-3 invocations of nmake, so you need to change all of them. | 12:34.13 |
| kens | Yeah, I must keep on missing one | 12:34.26 |
| | I *thought* I had them all :-( | 12:34.44 |
| chrisl | You can get the sbr files with a second nmake call | 12:35.30 |
| kens | Great, now I get a link error | 12:35.32 |
| | x86 conflicts with x64 :-( | 12:35.50 |
| | clean and rebuild | 12:36.22 |
| chrisl | Are you running 64 bit windows? | 12:36.24 |
| kens | yes | 12:36.31 |
| chrisl | nmake psi\msvc32.mak DEVSTUDIO= BUILD_SYSTEM=64 | 12:36.38 |
| kens | Oh... | 12:36.45 |
| chrisl | There is actually a way to check the "bitness" these days, but not on older versions, hence we need to tell it | 12:37.33 |
| kens | Fair enough, I'm glad I normally use the project.... | 12:37.56 |
| | Just realised I should really do this with the 'working' version first. | 12:39.09 |
| | OMG now the executable 'can't find the DLL' | 12:40.46 |
| | Actually can't load the DLL. | 12:41.02 |
| | Back tothe project I think | 12:41.15 |
| | Ah the error is nothing to do with loading the DLL | 12:46.50 |
| | reboot time | 12:48.47 |
| | chrisl GS_LIB works OK for me, I'm sure you're right about SaGS experience being the problem with UTF8 | 12:54.53 |
| | I built GS with COMPILE_INITS=0 and ran it, I get a 'can't find gs_init.ps' error | 12:55.26 |
| | I then set GS_LIB=d:\ghostpdl\gs\Resource\Init and reran it, and it started up properly | 12:55.46 |
| | Same with -I=.... | 12:55.57 |
| | So GS_LIB is OK on to the other problems I guess | 12:56.27 |
| | OK I do see the undefined resource. | 12:57.53 |
| chrisl | Hmm, I wonder why it didn't work for me...... | 12:58.02 |
| kens | No idea to be honest. THe reason that {} bind fails is because its enumerating the ProcSet resoruces to look for ProcSets to match | 12:59.07 |
| | And can't find the ones I added to deal with PSCRIP5.DLL | 12:59.29 |
| | I guess this 'might' be related to filenameforall, but its really a problem with resourceforall I would say, because presumably its finding the names one way but not in another | 13:00.41 |
| | Oh strange, the ProcSet resource is not present on disk | 13:01.38 |
| | That's.... odd..... | 13:01.58 |
| chrisl | No, isn't that one of the ones we define explicitly during initialisation? | 13:02.13 |
| kens | Yes, but I added (I thought) a bunch of idiom, now I need to see how I did it | 13:02.39 |
| | I had assumed I put them on disk | 13:02.55 |
| chrisl | IdiomSet not ProcSet | 13:03.50 |
| kens | D'oh! | 13:03.59 |
| | OK so there is the idiom, now what does it not like.... | 13:04.18 |
| tor7 | Robin_Watts: about the banding, adding banded output to PNG shouldn't be any more difficult. just a new IDAT section for each band. | 13:05.43 |
| Robin_Watts | tor7: Have you looked at my patch? | 13:06.03 |
| tor7 | looking through your patches on robin/master now | 13:06.14 |
| Robin_Watts | ok. | 13:06.23 |
| | THe tricky thing is going to be finding the nicest API. | 13:06.33 |
| tor7 | write_header/band looks fine to me. might need write_trailer as well. | 13:07.29 |
| kens | chrisl OK it does look like there's a problem here, the IdiomSet is present, but if I do (*) {==} 256 string /IdiomSet resourceforall, the resource comes back as (et/Pscript5Idiom), clearly the 'et/' should not be there | 13:07.55 |
| | Let me try this with / | 13:08.32 |
| tor7 | Robin_Watts: all that PNG needs is an empty IEND chunk after all the IDAT band chunks | 13:09.09 |
| Robin_Watts | tor7: write_trailer could do the close too. | 13:09.28 |
| kens | chrisl So '/' in GS_LIB does indeed work correctly, the Idiom is properly recognised | 13:09.51 |
| Robin_Watts | and I'd like to wrap up any state into a handle.a | 13:10.02 |
| kens | Its the '\' that does it. | 13:10.05 |
| tor7 | Robin_Watts: depends, if you're writing to a fz_output that goes into a zip container (like for xpswrite) that may not be ideal | 13:10.07 |
| Robin_Watts | and probably we should use fz_output rather than FILE *. | 13:10.21 |
| | tor7: Well, the fz_output would need to be closed, even if the zip container wasn't. | 13:10.58 |
| tor7 | Robin_Watts: right. | 13:11.05 |
| | but I prefer having open and close at the same "level" in the code | 13:11.16 |
| | so fz_write_png_to_file() would both open and close, but fz_write_png(output) wouldn't close (because it didn't open) | 13:11.47 |
| Robin_Watts | Well, the write_header does the open. | 13:12.03 |
| | so the write_trailer should do the close to match, ideally. | 13:12.14 |
| | I agree that things should match. | 13:12.54 |
| tor7 | right. write_trailer should really be named open_and_write_trailer | 13:13.06 |
| | ahem. write_header and open_and_write_header | 13:13.19 |
| | then write_trailer_and_close | 13:13.26 |
| | I'd move the opening away from the trailer while switching to fz_outputs | 13:13.48 |
| | I keep writing trailer when I mean header... | 13:13.57 |
| Robin_Watts | yeah. I'll fiddle with updating the patch to do png and to be 'nicer' later. | 13:14.22 |
| | cor, pi takes ages to build stuff :( | 13:14.43 |
| tor7 | Robin_Watts: sounds good. want this pushed in the meanwhile or you plan on hanging on to it on your branch? | 13:16.53 |
| Robin_Watts | I'll hang onto it until it's right. | 13:17.29 |
| tor7 | I'm happy with the other three. want me to push those in the meanwhile? | 13:17.42 |
| | Robin_Watts: what're you doing with the pi? | 13:18.20 |
| Robin_Watts | tor7: I want to profile mupdf on it to see if there is an obvious hotspot. | 13:21.46 |
| | MuPDF beats gs at 600dpi, but loses out at 1200dpi. | 13:22.17 |
| | I think our performance pretty much scales by number of pixels. | 13:22.20 |
| tor7 | Robin_Watts: I suspect that gs may be using "smarter" algorithms, but lose a lot of startup overhead due to complexity | 13:22.22 |
| kens | chrisl I think I can (sort of) see what's going on but I'll need to work on it. I won't get this fixed today as I'mgoing out in an hour | 13:22.37 |
| Robin_Watts | We'll see. | 13:22.38 |
| tor7 | we got a bug report about mupdf being much slower than older versions... it would be interesting to see how older releases compare. | 13:22.39 |
| Robin_Watts | tor7: I looked into that. | 13:22.40 |
| | He was comparing debug with release. | 13:22.41 |
| tor7 | ah! | 13:22.41 |
| Robin_Watts | which was nice to know after it cost me a mornings work. | 13:22.41 |
| | The addition of contexts lost us a bit (10-20%), but that's the only change in performance I could find. | 13:23.20 |
| | (At least I think it was that) | 13:23.25 |
| tor7 | that sounds about expected | 13:24.31 |
| | both the setjmp and extra argument overhead | 13:24.37 |
| kens | chrisl I believe I see the problem and its a simple fix. | 13:32.04 |
| chrisl | kens: that's good :-) | 13:32.22 |
| kens | THe old code converted '\\' into '\', which I accidentally removed | 13:32.47 |
| henrys | kens, chrisl:thanks for looking at that one. I only bisected between 9.00 to 9.01 and the file worked when we went to X11 | 13:38.58 |
| kens | NP henrys, but it will be quite an effort to find the other fix(es) that would be required to supply a working patch | 13:39.36 |
| henrys | kens:yes fine by me. | 13:40.11 |
| kens | I was planning to leave it to Marcos to contact the customer, if that's OK ? | 13:40.33 |
| henrys | my laptop wouldn't start this weekend so I went to the genius bar at the Apple Store and was greeted by a fellow who actually has "genius" printed on his business. I had visions of Wile E. Coyote and considered fixing it myself. But all went well. | 13:42.45 |
| | s/business/business card | 13:43.01 |
| | kens:yes that is the plan for all support ;-) yeah | 13:43.56 |
| kens | :-) | 13:44.07 |
| henrys | very annoying with this customer, michael volunteered to go out and help him upgrade. I hope marcosw gives him a stern response. | 13:50.37 |
| kens | Michael offered to go and help ? Are they local to him ? | 13:51.12 |
| henrys | no they are in a very nice place that michael would like to go ... | 13:51.56 |
| kens | Ah :-) | 13:52.02 |
| Robin_Watts | Gah. Looks like I'm gonna have to build my own raspberry pi kernel :( | 13:53.21 |
| chrisl | Why> | 13:53.44 |
| | ? | 13:54.02 |
| Robin_Watts | I want oprofile support. | 13:54.20 |
| | I've built oprofile, and it seems to run OK, but I never get any samples recorded. | 13:54.43 |
| chrisl | Oh, does that even work on ARM? | 13:54.48 |
| Robin_Watts | chrisl: yes. | 13:54.53 |
| | I use it the beagleboard all the time. | 13:55.01 |
| chrisl | Might be a suitable kernel in the repo? | 13:55.27 |
| Robin_Watts | Professor google hasn't found it for me, but I will check. | 13:55.54 |
| chrisl | No doesn't look like it | 13:56.37 |
| | You could use valgrind - if you're not in a hurry....... | 13:57.07 |
| kens | chrisl I have a fix, but no realistic way to test it, since the cluster does not test the Windows file system code. GS_LIB works with / and \, GS starts up, it finds the IdiomSet resources and some randomg filenameforall all seem to be OK. | 13:58.23 |
| | I'm incl;ined to push this, any dissent ? | 13:58.47 |
| chrisl | kens: there are some CET/FTS files that test filenameforall | 13:58.58 |
| kens | chrisl if you can tell me whic ones they are I will run them | 13:59.16 |
| chrisl | Hrm...... | 13:59.32 |
| kens | I'm off out in 15 minutes | 13:59.44 |
| Robin_Watts | actually.. gperftools works, apparently. Will try that. | 13:59.54 |
| chrisl | kens: just push it, I'll check the QL files with it | 14:00.10 |
| kens | OK | 14:00.16 |
| henrys | where are these jei files? | 14:00.22 |
| chrisl | henrys: I got them from rayjj's user area on casper | 14:00.58 |
| henrys | okay thanks | 14:01.09 |
| chrisl | JEITA_PDF.tar.gz | 14:01.29 |
| | That's a subset, I think | 14:01.43 |
| kens | chrisl commit d6921b5c5ab2af44c48e0084e4a31bcd7512f183 is there now if it causes problems pull it back out again but I htink it should be OK | 14:08.04 |
| Robin_Watts | I was going to commit the JEITA files to svn this morning, but noticed there were no PS files in rays area. | 14:08.17 |
| chrisl | kens: Okay. Did we handle just "\"? | 14:08.55 |
| | rather than "\\" | 14:09.06 |
| kens | Just '\' should have been fine | 14:09.10 |
| | But it gets translateed to '\\' at a highre level, my GS_LIB had '\' in it | 14:09.32 |
| chrisl | Okay, thanks | 14:09.32 |
| kens | Off out for a while, by all | 14:09.59 |
| henrys | chrisl:I don't know how complex these files are but the ppm's look low. | 14:53.55 |
| chrisl | henrys: they're quite complex. And the Pi is quite slow | 14:56.51 |
| | On mine, particularly writing files to the card is slowq | 14:57.34 |
| henrys | chrisl: I get engine speed on Color Laserjet 4700 but they've been converted to PS first. | 14:59.15 |
| | the laser jet has a similar processor frequency wise. | 14:59.36 |
| | I was hoping to avoid the "are you high?" meeting experience for michael. Been there done that. | 15:00.55 |
| chrisl | henrys: I don't know if Michael took the timings writing the output to disk, or to /dev/null | 15:02.26 |
| Robin_Watts | henrys: You think he'll be laughed out of the room? | 15:02.39 |
| henrys | the ppm numbers are very low and that is concerning. | 15:04.16 |
| chrisl | henrys: you can't say that without a sane comparison | 15:04.46 |
| henrys | maybe he should run the PDF manual - I know that runs 30 ppm on my printer. | 15:05.07 |
| chrisl | henrys: okay if you don't include the transparency pages | 15:05.51 |
| henrys | I didn't think the transparency pages used transparency I thought they were flattened images. | 15:06.35 |
| | but we could do the postscript manual | 15:06.44 |
| Robin_Watts | Let me try the pdf_reference manual here. | 15:06.55 |
| henrys | the color laser jet is a zoran rip and the processor is something like 600 mhz but it does have an ASIC | 15:08.25 |
| chrisl | Most of the LJ's have hardware assist rendering, and many have h/w assist for decompression, too | 15:09.19 |
| | Hmm, actual command lines would have been nice..... | 15:12.06 |
| Robin_Watts | build/release/mudraw -o out.ppm -B424 -r1200 ../MyTests/pdf_reference17.pdf -m 1 | 15:12.52 |
| | Assuming you have the changes to do banding. | 15:13.03 |
| henrys | chrisl: right I said an ASIC | 15:13.10 |
| chrisl | Robin_Watts: I meant for GS | 15:13.26 |
| | henrys: yes, I was agreeing with you | 15:13.35 |
| henrys | and the numbers must be wrong. How can halftoning have no appreciable affect on performance? | 15:14.28 |
| chrisl | Less memory to deal with | 15:15.07 |
| Robin_Watts | because gs doesn't "draw in contone, then halftone from that". | 15:15.12 |
| henrys | oh sorry I was reading it wrong. | 15:15.22 |
| Robin_Watts | for files will transparency there will be a hit. | 15:15.40 |
| | When is michaels trip? | 15:16.26 |
| henrys | miles told me and I forgot but soon within 2 weeks. | 15:18.33 |
| | chrisl: I wonder if HP has an FPU though. | 15:19.03 |
| | ? | 15:19.04 |
| Robin_Watts | ok, but not "tomorrow" :) | 15:19.11 |
| chrisl | henrys: I can't remember. Is it PPC? | 15:19.33 |
| henrys | I thought mips on the 4700 | 15:19.43 |
| | and I heard ray say there were problems with the pcl files being slow? I guess I should profile those. | 15:21.50 |
| chrisl | henrys: does the 4700 have PS as standard, or is it an option? | 15:25.46 |
| henrys | option I do have the printer | 15:29.06 |
| | I do have PS on the printer | 15:29.17 |
| chrisl | So, sometimes the PS option is a plugin board with extra memory and processing | 15:29.38 |
| | I can't find any real specifics on the LJ4700 hardware | 15:30.58 |
| henrys | chrisl: that is true, yes. It is not an Adobe rip though. | 15:31.02 |
| Robin_Watts | Hmm. It's possible that we can double all the mupdf speeds by just not writing the output :) | 15:31.05 |
| chrisl | Robin_Watts: I did mention that above | 15:31.22 |
| Robin_Watts | chrisl: yes, but it's taken me until now to actually try it. | 15:31.38 |
| chrisl | I'm still building gs..... | 15:31.49 |
| Robin_Watts | The pi is rather busy at the moment, so I don't consider it confirmed yet though. | 15:31.52 |
| | I think mvrhel was writing to /dev/null for gs. | 15:32.06 |
| chrisl | That's why I'd have liked a command line - it make it more easily reproducible | 15:32.43 |
| henrys | chrisl: the pcl might be a more reliable comparison against the 4700 | 15:33.38 |
| chrisl | is not convinced we should be spending time supporting 8.71....... | 15:35.38 |
| Robin_Watts | Also, Michaels timings were for single core CPIs. | 15:48.20 |
| | CPUs. | 15:48.23 |
| | What were we told about the CPU that they wanted timings for? It may be that the pi is a bad choice. | 15:49.17 |
| | The pi is an ARMv6 thing, and more modern ARMs are ARMv7. | 15:49.31 |
| | The FP timings are different between the two. | 15:49.42 |
| henrys | I don't really know what's happening miles has been telling michael what to do. At the end of the day we need to do a comparison against zoran on a printer like architecture. | 15:51.19 |
| | I guess when we seen a patch we could cluster push the unlatched followed by the patched and see what's changed. maybe marcosw already does that. | 16:12.07 |
| | s/seen/send | 16:12.14 |
| ojno | hi, I've been having problems with the "*** File has unbalanced q/Q" infinite loop with pdfwrite, has anyone run into this before? I have seen various bug reports but they're all listed as fixed and I get this even when running latest from git | 16:12.17 |
| henrys | s/unlatched/unpatched/ - phew | 16:12.31 |
| ojno | I have an example which always fails, and weirdly it doesn't happen with -dNOTRANSPARENCY | 16:13.09 |
| | but unfortunately I kind of need transparency | 16:13.16 |
| | and unlike the previous bug reports, the input PDF file seems to be fine, no complaints from acrobat or any other readers | 16:13.58 |
| Robin_Watts | ojno: Can you open a bug on bugs.ghostscript.com please with the input PDF file, and the exact command you are calling? | 16:14.12 |
| henrys | ojno: sounds worthy of a bug report to me. at bugs.ghostscript.com, include the command line, test file and version number. | 16:14.14 |
| | hah stereo | 16:14.40 |
| ojno | will do. Just wanted to make sure it wasn't my fault first ;) | 16:14.43 |
| henrys | chrisl: the xl jobs I've looked at so far a engine speed too, well I had a pause after one page. | 16:18.50 |
| chrisl | henrys: Are you piping XL files directly to the printer? | 16:21.02 |
| henrys | yeah I use -l with lpr - which sends it raw. | 16:23.24 |
| | too bad there is no native pdf support. | 16:25.10 |
| chrisl | Well, I rather expect that, or close, anyway. PXL is much simpler to interpret than PS | 16:25.36 |
| henrys | chrisl: but rendering the graphics is going to be the bottleneck at 600 dpi color. | 16:28.21 |
| chrisl | henrys: not necessarily - depends on the PS. Also, IIRC, PXL doesn't have shadings, limited color spaces, etc etc | 16:29.10 |
| marcosw | henrys: I only test patches on the cluster if they are complicated (and usually not on the cluster, I just run them locally). | 16:29.52 |
| henrys | If I could figure out how to capture the postscript when printing the pdf files we could test those files against the 4700 then we'd have a better comparison. | 16:29.52 |
| chrisl | No idea. It's doable on Windows | 16:30.24 |
| henrys | chrisl:yes probably the only thing I know how to do on windows and not on a mac. | 16:30.54 |
| chrisl | henrys: But then you run into the problem that using the HP driver, you're potentially using PS optimised for their printer. | 16:31.35 |
| henrys | chrisl: anything of modest compelexity turns into hell in pcl tiny rectangles rope all that so it kind of evens out from what I've seen. | 16:33.15 |
| | s/rope/rops/ | 16:33.26 |
| ray_laptop | henrys: It's easy to capture the PS on Windows | 16:34.01 |
| Robin_Watts | ray_laptop: Morning | 16:34.17 |
| ray_laptop | Just add a printer and specify "FILE:" as the port | 16:34.22 |
| Robin_Watts | I was going to add the J files to the tests_private repo today. | 16:34.39 |
| chrisl | henrys: I'll remind you of that next time we a file with a 14 ink DeviceN color space image that's slow! | 16:34.50 |
| ray_laptop | chrisl: the problem with PXL and PCL that I captured from the J files is that they are hideously slow. | 16:35.10 |
| Robin_Watts | but 1) I don't have the PS versions, and 2) the PCL and PXL versions only appear to have 3 or 4 files. | 16:35.18 |
| ray_laptop | I suspect that they use RasterOps | 16:35.23 |
| henrys | ray_laptop:I'm a little nervous sending off 5 ppm numbers unless it is known the files are conspicuously slow. | 16:37.15 |
| ray_laptop | Robin_Watts: The problem with the PS files that I got from a customer is that many of them fail. Which reminds me I need to open a bug | 16:37.19 |
| | mvrhel tested PS files and they _are_ faster | 16:37.45 |
| | I've just been concentrated on cust 532's bug. Now it looks like the indexed colorspace lookup string from a PS ref isn't being tracked by the GC -- it got freed during a GC, but then showed up in the array to a setcolorspace | 16:40.48 |
| henrys | will somebody please send all the information to tech so we don't have to waste time? or if you want to do the project privately fine. But it is ridiculous to give us none of the background and then solicit our opinions about the final report. | 16:41.02 |
| | I'll definitely profile the pcl/pxl stuff shorty. | 16:42.01 |
| | shortly | 16:42.09 |
| marcosw | henrys: has anyone tried sending the 5 ppm files to a printer and see if they are in fact slow to print? | 16:42.12 |
| henrys | marcosw:yes read the logs | 16:42.27 |
| ray_laptop | henrys: I mentioned on here when working with mvrhel. did you need me to send the stuff to tech at artifex, too ? | 16:42.43 |
| | I wonder why mvrhel compared mupdf RGB against gs CMYK. I'd like to see the gs RGB numbers as well | 16:43.45 |
| Robin_Watts | ok, mupdf 600dpi 1st page of pdf_reference17.pdf to /dev/null = 13.7s. To out.ppm = 22.9s | 16:43.54 |
| henrys | ray_laptop:oh did I miss that? Generally I'm against any form of opaque project. Miles is notorious for starting those. | 16:43.57 |
| ray_laptop | even if CMYK is faster | 16:43.59 |
| Robin_Watts | ray_laptop: I'd really like to see the reasoning behind using the raspberry pi as the target device. | 16:44.34 |
| ray_laptop | Robin_Watts: is that the -m mode ? | 16:44.55 |
| Robin_Watts | ray_laptop: No. This is a new modification I just made. | 16:45.08 |
| ray_laptop | Robin_Watts: it's just a readily available ARM | 16:45.27 |
| Robin_Watts | ray_laptop: Right, but it's a readily available ARM with an odd FPU. | 16:45.34 |
| ray_laptop | mvrhel wanted something that somebody else had that he could get quickly. Beagleboard was the only other thing that was mentioned AFAIK | 16:46.09 |
| Robin_Watts | Right. | 16:46.24 |
| | I'll do some tests on the bb to see if it's comparable speeds. | 16:46.43 |
| ray_laptop | Robin_Watts: and marcos didn't mention any downside (you were on holiday) | 16:46.44 |
| marcosw | henrys: so the answer to your question, is it "known (that) the files are conspicuously slow", is no. | 16:46.52 |
| ray_laptop | Robin_Watts: is the BB a similar clock rate | 16:47.10 |
| Robin_Watts | ray_laptop: It is. | 16:47.21 |
| | 500MHz, IIRC. | 16:47.27 |
| ray_laptop | In looking at the website you posted, the Wandboard Quad looks cool 4 core at 1GHz :-) | 16:47.58 |
| henrys | marcosw:right I guess I should have said that and saved you some time. You probably don't need all the background. | 16:48.19 |
| chrisl | henrys: so, using "-dFirstPage=1 -dLastPage=50 -sDEVICE=bitcmyk -r1200 -o /dev/null -dBufferSpace=16777216 /home/pi/pdf_reference-core.pdf", gs does those 50 pages in ~1m47s, which works out to ~28ppm. | 16:48.45 |
| henrys | chrisl: well that is encouraging. | 16:50.26 |
| ray_laptop | chrisl: Robin_Watts: How do I build 64-bit Windows. I thought Robin_Watts had added a 64-bit choice in the solution/project files, but it doesn't show up in the configuration choice (just win32) | 16:50.42 |
| Robin_Watts | chrisl: Which 50 pages of pdf_reference17.pdf are they ? | 16:50.58 |
| | ray_laptop: Under "Win32" do you have an "x64" choice? | 16:51.18 |
| chrisl | Robin_Watts: -dFirstPage=1 -dLastPage=50 | 16:51.19 |
| ray_laptop | chrisl: and I tried raw nmake with WIN64=1 and that tries to load the 32-bit DLL | 16:51.22 |
| ray_laptop | goes to check | 16:51.34 |
| marcosw | henrys: sorry, I shouldn't have jumped in without reading the logs and without having anything useful contribute. | 16:51.49 |
| Robin_Watts | chrisl: Right. I'm confused by the "pdf_reference_core.pdf" bit. | 16:52.02 |
| | Is that a subset of the pdf_reference17.pdf file? | 16:52.12 |
| | just want to make sure I test the same thing here. | 16:52.22 |
| chrisl | ray_laptop: "nmake psi\msvc.mak DEVSTUDIO= BUILD_SYSTEM=64 WIN64=1" IIRC, works for me | 16:52.29 |
| henrys | marcosw:no I felt bad having you slog through that... | 16:52.34 |
| chrisl | Robin_Watts: it's the entire file, I'm just rendering the first 50 pages out of it | 16:52.47 |
| ray_laptop | Robin_Watts: It' on the top line under Active solution platform. I was looking on the individual projects. Thanks | 16:53.11 |
| chrisl | henrys: interestingly 600dpi isn't hugely faster at 33ppm | 16:53.47 |
| | ray_laptop: what's a good contone CMYK device? | 16:54.48 |
| ray_laptop | chrisl: the best one for benchmarking is -sDEVICE=bitcmyk -dGrayValues=256 | 16:55.44 |
| chrisl | ray_laptop: cool, thanks | 16:56.14 |
| henrys | marcosw:you should probably say AGPL | 16:56.23 |
| ray_laptop | Robin_Watts: It skips all the builds in x64 mode :-( | 16:57.12 |
| Robin_Watts | ray_laptop: WorksForMe(TM) | 16:57.48 |
| | mupdf at 1200dpi is giving me 50 seconds a page or so for pdf_refence17.pdf. That's awful. | 16:59.25 |
| ray_laptop | Robin_Watts: I only have 64-bit on 2005 (ver 8) | 16:59.26 |
| Robin_Watts | ray_laptop: Me too. | 16:59.36 |
| ray_laptop | version 8 | 16:59.37 |
| | I'm using the GhostPDL solution from the win32 directory | 17:00.08 |
| Robin_Watts | Is it possible that the build is up to date? | 17:00.18 |
| ray_laptop | Robin_Watts: it doesn't even start nmake. All it says is: | 17:02.38 |
| | 1>------ Skipped Build: Project: ghostscript ------ | 17:02.40 |
| | 1> | 17:02.41 |
| | ========== Build: 0 succeeded or up-to-date, 0 failed, 1 skipped ========== | 17:02.43 |
| Robin_Watts | Ah, well, maybe it doesn't think you have the 64bit stuff installed. | 17:03.04 |
| chrisl | henrys, Robin_Watts: if I use pdfwrite to create a PDF with only the first 50 pages from the pdf RM, I get get >50ppm/600dpi and 43ppm/1200dpi | 17:04.04 |
| ray_laptop | well, it _does_ try to build if I use nmake and give it WIN64=1 XCFLAGS="/D_WIN64 /D_AMD64_" | 17:04.11 |
| | but it fails when it tries to run genarch.exe | 17:04.37 |
| Robin_Watts | The sole difference in the configurations is that the x64 ones give WIN64= | 17:05.04 |
| chrisl | ray_laptop: is it a 64 bit Windows install? | 17:05.04 |
| mvrhel_laptop | ok I see there are lots of comments about the timing results. | 17:05.33 |
| | henrys: there were no real emails that people were left out of. | 17:06.08 |
| | other than the original email that suggested the use of the certain JEITA files | 17:06.28 |
| ray_laptop | chrisl: yes | 17:06.31 |
| chrisl | mvrhel_laptop: yeh, amongst henrys's rants about not doing things "behind the scenes", we were thinking it would be good include numbers from a better known file or two, like the PDFRM | 17:06.35 |
| mvrhel_laptop | ok. I dont think I was doing things behind the scenes too much. I had dragged you in to do some numbers and Robin wrote code for me and ray helped | 17:07.29 |
| henrys | mvrhel_laptop: okay I though I was missing a lot of stuff, if not sorry for the rant. | 17:08.17 |
| Robin_Watts | mvrhel_laptop: I'm having trouble reproducing your numbers here. | 17:08.24 |
| chrisl | ray_laptop: I use the VS command prompt for x64, and I build using "nmake -f psi\msvc.mak DEVSTUDIO= BUILD_SYSTEM=64 WIN64=1" for an optimised build. | 17:08.25 |
| mvrhel_laptop | Robin_Watts: on your raspberry pi? | 17:08.40 |
| Robin_Watts | yeah. | 17:08.44 |
| mvrhel_laptop | what are you getting? | 17:08.49 |
| Robin_Watts | build/release/mudraw -m -F ppm -o out -B424 -r1200 ../MyTests/J9_acrobat.pdf | 17:08.56 |
| mvrhel_laptop | what is -F? | 17:09.05 |
| chrisl | mvrhel_laptop: my only "rant" was that it would be good if you included the exact command lines so other could reproduce what you did | 17:09.08 |
| henrys | mvrhel_laptop: but the 5 ppm numbers are alarming I don't think we want to send those off until we know these files are conspicuously slow. | 17:09.22 |
| Robin_Watts | mvrhel_laptop: Oh, sorry -F is a new flag I added today, so you can give a format. | 17:09.28 |
| mvrhel_laptop | chrisl ok fair enough | 17:09.28 |
| Robin_Watts | build/release/mudraw -m -F ppm -o /dev/null -B424 -r1200 ../MyTests/J9_acrobat.pdf | 17:09.37 |
| mvrhel_laptop | ok for mupdf I had the no AA build | 17:09.50 |
| | with -m | 17:09.55 |
| Robin_Watts | mvrhel_laptop: Of course! Sorry. | 17:09.59 |
| mvrhel_laptop | and -r1200 or -r600 | 17:10.07 |
| | and -B at the values that I show in the table | 17:10.22 |
| | hmm. for gs, I see that I may have made a mistake. the damn BandListStrorage was set to file. It was supposed to be memory | 17:12.31 |
| | let me start this back up. | 17:12.51 |
| | need to take daughter to soccer. bbiab | 17:12.59 |
| Robin_Watts | Damn. I've got a mistake here somewhere. | 17:13.26 |
| ray_laptop | mvrhel_laptop: gs builds do default to file -- pcl defaults to memory (don't ask me why) | 17:14.44 |
| henrys | ray_laptop:the thinking was pcl would be targeted at a low end printer without a disk drive. | 17:16.32 |
| chrisl | ray_laptop: we can switch to memory at the commend line? | 17:16.41 |
| ray_laptop | chrisl: I used: nmake -f psi\msvc.mak BUILD_SYSTEM=64 WIN64=1 DEBUG=1 TDEBUG=1 DEVSTUDIO= and it completes the build, but then "load_dll" tries to load gsdll32.dll because _WIN64 is not set | 17:17.46 |
| | not #defined, that is | 17:18.02 |
| | chrisl: yes, I added command line switching some time ago. -sBandListStorage=memory | 17:18.31 |
| chrisl | ray_laptop: does that nmake invocation work without the debug settings? | 17:20.45 |
| ray_laptop | but -sBandListStorage=file will only work if it was built with the make BAND_LIST_STORAGE=file (it _always_ builds in the gxclmem stuff for pattern-clist, but it doesn't build in gxclfile unless the macro is set to file) | 17:20.47 |
| | chrisl: I don't see how it could work differently, but I'll try. | 17:21.17 |
| | chrisl: no. In this case I had gsdll32.dll in the bin directory, and it loads it, but I get "Wrong version of DLL found." because the DLL was built for 909 and I'm now up to 910. | 17:26.09 |
| | chrisl: can you move your bin/gsdll32.dll out of the way and see if you can run gswin64c.exe ? | 17:27.11 |
| chrisl | ray_laptop: I get a missing DLL error if I try to build the 64 bit version in the x86 command prompt window | 17:27.21 |
| ray_laptop | chrisl: OK. so I'm not crazy. | 17:27.39 |
| chrisl | ray_laptop: if I use the "Visual Studio 2005 x64 Win64 Command Prompt" it works fine | 17:29.21 |
| ray_laptop | oh, great :-( | 17:30.48 |
| chrisl | It's always been that way (at least, since I was involved) - it seemed fairly logical, to me..... | 17:32.15 |
| ray_laptop | chrisl: How do I start that ? | 17:32.21 |
| | is that from the IDE somehow ? | 17:32.46 |
| chrisl | It's in the VS start menu group, under "Visual Studio Tools" | 17:33.00 |
| Robin_Watts | ray_laptop: VS has a couple of batch files to set the paths for the different compilers up | 17:33.03 |
| | vcvars.bat and vcvars64.bat or something like that. | 17:33.16 |
| | And the "Visual Studio 2005 x64 Command Prompt" is just a command prompt where one of those batch files has been run first. | 17:33.41 |
| | It's not in the IDE. | 17:33.45 |
| | It might be in the start menu entry? | 17:33.54 |
| ray_laptop | Robin_Watts: I was just running vsvars.bat (renamed to vsvars8.bat) | 17:33.54 |
| Robin_Watts | ray_laptop: Right. That configures the 32bit compilers. | 17:34.08 |
| | You need vsvars64.bat or something like that. | 17:34.25 |
| | %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 8\VC\vcvarsall.bat"" amd64 | 17:34.59 |
| ray_laptop | Trying what chrisl suggested (from the Start menu Microsoft Visual Studio 2005 / Visual Studio Tools / Visual Studio 2005 Command Prompt | 17:35.44 |
| | I still get the same error. Trying a build after clean | 17:38.44 |
| chrisl | ray_laptop: it is the "x64 Win64" command prompt? | 17:39.13 |
| ray_laptop | chrisl: it doesn't say that. There's only one command prompt choice in the Visual Studio Tools menu | 17:40.37 |
| Robin_Watts | ray_laptop: Then you haven't (properly) installed the 64bit compilers. | 17:40.53 |
| ray_laptop | hates Microsoft software | 17:41.21 |
| Robin_Watts | I have a choice of 3 command prompts. | 17:41.22 |
| | The one you mention, one for cross compiling and one for 64bit, | 17:41.44 |
| ray_laptop | I used to be able to do this :-( | 17:42.59 |
| | Robin_Watts: what follows the vcvarsall.bat in the Properties for the 64-bit command prompt ? | 17:48.20 |
| Robin_Watts | What I pasted above. | 17:49.02 |
| | amd64 | 17:49.10 |
| ray_laptop | Robin_Watts: Oh, sorry missed it | 17:49.28 |
| | looks like I have to reinstall the tools :-( | 17:51.38 |
| | Robin_Watts: chrisl: thanks. | 17:51.57 |
| chrisl | ray_laptop: NP, for all it was worth..... | 17:52.24 |
| ray_laptop | well, it explains why WORKSFORME == false | 17:52.51 |
| chrisl | ray_laptop: FWIW, I just did a 64 bit debug build from the VS2005 IDE and it works as expected. | 17:57.12 |
| ray_laptop | chrisl: yeah, probably the IDE should have told me when I tried to build, rather than just silently skipping it | 17:58.37 |
| | as I said above /me hates Microsoft | 17:59.08 |
| chrisl | ray_laptop: that would be nicer, but it may be because we sneakily call nmake instead of it being a "real" VS build | 17:59.19 |
| Robin_Watts | chrisl: No, it's likely to be because the installation has forgotten that it has 64bit tools installed. | 18:02.16 |
| | hence it skips the projects it can't make. | 18:02.39 |
| | rather than trying them and failing. | 18:02.48 |
| chrisl | Robin_Watts: I meant the reason it might not throw an obvious error | 18:02.48 |
| | henrys: just for comparison, I tried the J9 PDF file from the JEITA archive with pdftoppm (the poppler tool): it took 4m16.124s to render at 600dpi, which is 1.17ppm | 18:03.32 |
| ray_laptop | chrisl: how fast is gs on the same system ? | 18:04.31 |
| chrisl | ray_laptop: just a sec..... | 18:05.27 |
| | ray_laptop: I'm just going to rerun gs with a configuration more comparable to pdftoppm | 18:07.10 |
| ray_laptop | I assume that poppler doesn't do banding, does it ? | 18:09.38 |
| | chrisl: i.e., how much memory does poppler use ? | 18:09.54 |
| chrisl | ray_laptop: poppler does *seem* to do some kind of banding - i.e. it seemed to be writing the output files in "bands" | 18:10.42 |
| | ray_laptop: I ran gs with "-sDEVICE=bitrgb -r600 -o gs%03d.ppm -dBufferSpace=16777216 -sBandListStorage=memory -dGrayValues=256" | 18:11.06 |
| ray_laptop | chrisl: you can get some idea of memory usage from top | 18:11.08 |
| chrisl | and J9 ran in 2m3.580s | 18:11.28 |
| ray_laptop | chrisl: how fast to /dev/null ? | 18:11.46 |
| | writing 600 dpi RGB contone can be significant | 18:12.21 |
| chrisl | ray_laptop: I don't know - I haven't fathomed if pdftoppm can write to /dev/null and I wanted a fair comparison | 18:12.23 |
| ray_laptop | chrisl: no, I meant gs | 18:12.36 |
| chrisl | ray_laptop: yes, but I'm trying to compare the two..... | 18:13.03 |
| ray_laptop | just to see how much time gs is spending writing the file | 18:13.08 |
| | because presumably poppler is spending that much as well | 18:13.26 |
| | but still, we are more than twice as fast | 18:13.55 |
| chrisl | So, pdftoppm writing to /dev/null completed in 0m51.804s and used ~147Mb | 18:14.44 |
| | gs, writing to /dev/null completed in 0m49.355s and used ~30Mb | 18:15.29 |
| | Disappointingly, if I let gs use more memory (so -dBufferSpace=167772160) then only gets very slightly faster: 0m46.732s | 18:17.44 |
| ray_laptop | chrisl: just to make it easier for me to read, how about using 16m instead of 16777216 ;-) | 18:18.41 |
| chrisl | ray_laptop: I thought -d options had to be true/false or integers? | 18:19.45 |
| ray_laptop | chrisl: try -dMaxBitmap=160m | 18:19.51 |
| | some time ago I added the unix style suffixes to numbers. so 16m _is_ an integer | 18:20.27 |
| | we have k m and g suffixes | 18:20.40 |
| chrisl | So, what's BufferSpace? | 18:20.46 |
| | ray_laptop: "-sDEVICE=bitrgb -r600 -o /dev/null -dMaxBitmap=160m -sBandListStorage=memory -dGrayValues=256" still takes 0m47.193s | 18:21.39 |
| | I really thought a larger band size would show more benefits | 18:21.54 |
| ray_laptop | hmm.. with -dBufferSpace=160m I don't see banding, so I guess you don't need -dMaxBitmap=160m | 18:23.28 |
| | usually page buffer mode is faster. | 18:23.39 |
| | on my laptop, J9 is 2.1 seconds to /dev/null (BufferSpace = 16m or 160m) | 18:25.11 |
| | what are you on that it is taking 49 sec ? | 18:26.06 |
| chrisl | ray_laptop: RaspberryPi | 18:26.18 |
| ray_laptop | oh. Sorry. I thought you were on a real machine | 18:26.34 |
| Robin_Watts | I can't reproduce michaels timings :( | 18:26.49 |
| | I've done the same build that he has (I think) | 18:26.59 |
| | and I'm getting much slower results. | 18:27.31 |
| ray_laptop | mvrhel was going out to /dev/null | 18:27.58 |
| chrisl | ray_laptop: on my desktop Linux machine it takes 2.3 seconds writing to /dev/null | 18:28.07 |
| | So we're in the same ballpark for workstation performance | 18:28.27 |
| ray_laptop | so chrisl _is_ getting close to mvrhel's timing | 18:28.35 |
| Robin_Watts | ray_laptop: He wasn't going to /dev/null on mupdf, cos had he done so, he'd have been writing PNGs to /dev/null. | 18:28.42 |
| | *I'm* going to /dev/null with ppm's and I can't get close to his timings. | 18:29.09 |
| ray_laptop | mvrhel reported 51 sec. and 30Mb used | 18:29.15 |
| | Robin_Watts: he was using -m | 18:29.26 |
| Robin_Watts | -m still writes an output, I believe. | 18:29.38 |
| | I'm using -m too. | 18:29.46 |
| ray_laptop | which is _supposed_ to render the bitmap and then not write it | 18:29.48 |
| Robin_Watts | No, that's not what -m does. | 18:30.00 |
| ray_laptop | Robin_Watts: are you using -b 0 | 18:30.07 |
| Robin_Watts | I am. | 18:30.11 |
| ray_laptop | with gs using -o /dev/null on the p?mraw or bit* devices, it renders, but skips the fwrite | 18:31.11 |
| | to avoid fwrite memcopies to some intermediate buffer | 18:31.39 |
| Robin_Watts | ray_laptop: Indeed. MuPDF does not. | 18:31.58 |
| | so we still fwrite to /dev/null | 18:32.10 |
| ray_laptop | it's done for benchmarking to simulate direct DMA to a printer | 18:32.14 |
| Robin_Watts | I understand the logic. | 18:32.20 |
| ray_laptop | I thought tor said that it wouldn't | 18:32.33 |
| Robin_Watts | I'm looking at the code, and it looks like it's writing to me. | 18:33.08 |
| ray_laptop | so to be fair, mupdf -m really shouldn't do the fwrite | 18:33.13 |
| | strace ? | 18:33.29 |
| | I have to run pick up my son at tennis. bbiaw | 18:33.48 |
| chrisl | I think I'm going to call it a day....... | 18:36.21 |
| Robin_Watts | I take it back. -m does indeed not write the file out. | 18:37.32 |
| | and it makes a massive difference in speed! | 18:37.44 |
| | That's bonkers. | 18:37.51 |
| | well, actually, maybe it does make sense. | 18:38.36 |
| | right, so I can reproduce michaels times. | 18:39.06 |
| | Now I'll see if I can get gperftools working so I can profile. | 18:39.28 |
| atulagrwl | Hi all, I reported a bug http://bugs.ghostscript.com/show_bug.cgi?id=694527. Can somebody take a look at it? Somehow, I am thinking I am missing something. This should not be a problem. | 18:49.30 |
| mvrhel_laptop | ok finally back | 18:53.41 |
| | Robin_Watts: so are you seeing similar times as what I was getting? | 18:53.53 |
| | I agree that running something like the manual through would be good | 18:54.12 |
| Robin_Watts | mvrhel_laptop: Yes, I can duplicate your timings. | 18:54.14 |
| mvrhel_laptop | Robin_Watts: ok great | 18:54.18 |
| | thanks Robin_Watts | 18:54.23 |
| Robin_Watts | and my gperftools build just finished. | 18:54.41 |
| mvrhel_laptop | henrys: so we have timings for PCL from the competitor on a dual core 600Mhz ARM | 18:54.57 |
| | ray_laptop: had tried to generate some PCL files from the J9 J10 and J11 files | 18:55.21 |
| | but they apparently were really really slow | 18:55.28 |
| Robin_Watts | mvrhel_laptop: Which arm, do you know? | 18:55.51 |
| mvrhel_laptop | is there anything you can do to generate PCL data that will render more easily? | 18:55.52 |
| | hold on let me forward what I have to tech | 18:56.00 |
| Robin_Watts | 50 pages of pdf_reference17.pdf at 1200dpi is 2 seconds a page. | 18:56.49 |
| | with a 16Meg buffersiz | 18:57.52 |
| | e | 18:57.54 |
| mvrhel_laptop | oh that is ok | 18:58.09 |
| | can we go to skype chat for a sec? | 18:58.28 |
| | henrys: ? | 18:58.35 |
| henrys | yes I'm here | 19:00.18 |
| mvrhel_laptop | ok just got on and now scott has called me | 19:00.52 |
| henrys | ray_laptop:oh you generated the PCL and XL that were in the Jeita zips on casper? They aren't official test files? | 19:05.54 |
| mvrhel_laptop | henrys: no. | 19:13.39 |
| | see skype for sec... | 19:13.46 |
| henrys | okay | 19:13.57 |
| mvrhel_laptop | ray generated those himself using a PCL driver | 19:13.59 |
| | henrys: are there any special parameters I should know about before running the PCL files on the pi? | 19:29.15 |
| | oh one thing I mean to do was to check if any of the pdf files had interpolation of images going on | 19:30.43 |
| | will do that to after lunch. | 19:30.59 |
| | henrys: do you have any suggestions on command line params for PCL testing? | 19:47.09 |
| | starting pcl build on pi.... | 19:48.18 |
| Robin_Watts | ok, I now have a profiler library, and it SEEMS to be working. | 19:53.01 |
| ray_laptop | henrys: The PXL files were generated from the J PDF's using the "HP ColorLaserJet 9500 PCL6" driver. For the color PCL files I used the "HP Color LaerJet CP3505 PCL 5c" driver. The JEITA source files are in application format, designed to be printed from the app to get a particular format. | 20:02.48 |
| | henrys: the only one I have in "original" form is J9.ppt | 20:04.16 |
| | I'll upload that to ~ray/public in case anyone wants to use PowerPoint to print to a different driver and see if it makes a difference. | 20:05.38 |
| | oops. it's only J11.ppt that I have. I didnt' recall correctly | 20:07.06 |
| | OK. It's up there. | 20:08.13 |
| tor7 | Robin_Watts: paulgardiner: https://groups.google.com/forum/#!topic/v8-users/MUq5WrC2kcE | 20:08.54 |
| | looks like a lot of the v8 stuff we've done will need to be redone if we ever upgrade | 20:09.13 |
| mvrhel_laptop | ray_laptop: where does one get the originals? | 20:11.10 |
| | do you have to purchase them? | 20:11.14 |
| ray_laptop | mvrhel_laptop: from JEITA. Yes, and they aren't that pricey. | 20:11.44 |
| | iirc | 20:11.53 |
| mvrhel_laptop | ok we should just get them. | 20:12.01 |
| ray_laptop | Tje problem is that any actual set of files generated will depend a lot on what printer driver was used to make the files, and to some degree, to what version of the app is used to print | 20:13.19 |
| mvrhel_laptop | right | 20:13.28 |
| | I guess the best thing would be to get the pdf, pcl and ps files from a customer that they want to use for benchmarking | 20:14.04 |
| atulagrwl | Do we have some mailing list for mupdf dev discussion? | 20:14.08 |
| ray_laptop | and you have to be careful in that some newer MS apps don't generate the right thing from older files. That's common with PPT, less so with .doc or .xls | 20:14.34 |
| | unfortunately, with Japanese customers the JEITA files are widely used (or misused). Using some PDF 1.7 ATS files would be better since those are already in the standard format. | 20:17.29 |
| mvrhel | ray_laptop: yes I agree the ATS tests are better | 20:22.44 |
| mvrhel_laptop | henrys: you there? | 21:09.51 |
| ray_laptop | mvrhel: Well, I might get some useful info. Except CPSI is taking a LONG time. The 'console' RAM free numbers are changing, but it seems stalled at 66% | 21:29.52 |
| mvrhel | ray_laptop: ok great. I will keep my fingers crossed | 21:30.11 |
| ray_laptop | maybe I should have started with J9 instead of J11 | 21:30.13 |
| | it looks like it gives me RIP time. Also I wonder if this is so old that it doesn't support transparency ? | 21:31.06 |
| | that _might_ be the page it is stalled on | 21:32.02 |
| mvrhel | right | 21:33.00 |
| ray_laptop | Going to kill it and see about the other 2 | 21:33.05 |
| mvrhel | running pcl on rasberry pi now | 21:37.10 |
| ray_laptop | Great! I get the RIP time, independent of the windows driver. so J9 took 36 seconds for 600x600 RGB. J10 gets an exception and J11 hangs (I am going to try it again and just let it run) | 21:48.40 |
| mvrhel_laptop | ray_laptop: ok great | 21:50.48 |
| | perhaps we should compare the PS files? | 21:51.07 |
| | to avoid the hanging and exception issues? | 21:51.18 |
| ray_laptop | now to copy over gs. | 21:51.21 |
| mvrhel_laptop | PCL is still running on raspberry pi :( | 21:51.29 |
| | I fear the times are going to be horrid | 21:51.40 |
| ray_laptop | I have to generate the PS files (I didn't send them to you did I ?) | 21:51.52 |
| mvrhel_laptop | ray_laptop: yes | 21:51.58 |
| | you did | 21:52.00 |
| | I have them | 21:52.02 |
| | they are in your public dir I think | 21:52.20 |
| | oh no they are not | 21:52.38 |
| | oh, I generated my own | 21:54.02 |
| | that is right | 21:54.04 |
| | from ps2write | 21:54.09 |
| | ray_laptop ^^ | 21:54.13 |
| ray_laptop | Oh, that's right. We _should_ compare those to PS files from a PS printer driver. | 21:55.01 |
| | and use whichever is better. | 21:55.24 |
| | mvrhel: I used gs and Acrobat to convert the files to PS. I'm going to try them with CPSI, and get the comparable timings with gs HEAD | 22:12.42 |
| | mvrhel: I'm not going to bother with the files exported by Acrobat 9. On my laptop gs is faster with all three using ps2write output :-) and the files are smaller ! | 22:16.46 |
| henrys | mvrhel_laptop: which pcl file did you confirm slow? | 22:17.11 |
| | ray_laptop:wow that's some strange pcl | 22:27.07 |
| mvrhel_laptop | ok pcl finished on raspberry pi | 22:27.46 |
| ray_laptop | henrys: It's what came from the driver I mentioned above | 22:27.48 |
| mvrhel_laptop | henrys: do you have some better ones you can generate? | 22:28.04 |
| henrys | yes it's in the file too 3505 | 22:28.05 |
| mvrhel_laptop | for me to use? | 22:28.07 |
| henrys | ray_laptop:just needs to install the 4700 driver and repeat. | 22:28.57 |
| ray_laptop | I don't know where to get a 4700 color PCL5 driver | 22:29.27 |
| mvrhel_laptop | henrys: can you generate the files? | 22:29.38 |
| henrys | I'll look I don't have acrobat running on windows | 22:31.15 |
| | ray_laptop:it's right here http://h20000.www2.hp.com/bizsupport/TechSupport/DriverDownload.jsp?prodNameId=473039&lang=en&cc=us&prodTypeId=18972&prodSeriesId=473038&taskId=135 | 22:32.55 |
| ray_laptop | henrys: can you look at the PCL generated by CPSI and tell me what it is? It displays file with pcl6 -r600 | 22:33.26 |
| | it's on ~ray/public/J9_cpsi_HP4500.pcl | 22:33.55 |
| henrys | yes | 22:34.00 |
| ray_laptop | henrys: thanks | 22:34.06 |
| henrys | it's going to faster if you just quickly install that driver and print. But I can set it up if you want. | 22:34.33 |
| mvrhel_laptop | so J11 is running like 2.3 ppm at 600dpi contone | 22:34.49 |
| ray_laptop | I mostly want to know if it's just a bitmap, and if so, whether it is contone or not | 22:34.52 |
| mvrhel_laptop | J11.pcl | 22:34.52 |
| | we are not even close to Z with these files | 22:35.42 |
| henrys | ray_laptop 600 dpi rgb contone | 22:37.25 |
| mvrhel_laptop | henrys: so the 4700 driver output files will probably be faster | 22:37.31 |
| | ? | 22:37.33 |
| henrys | mvrhel_laptop: I thought j10 was very odd let me look at j11 | 22:38.03 |
| ray_laptop | mvrhel: gs blows cpsi away. J11_gs.ps takes gs 9 seconds to contone RGB, 12 seconds to 1-bit RGB, 9 9seconds to contone CMYK, and 13 seconds to 1-bit CMYK | 22:39.13 |
| mvrhel_laptop | ray_laptop: great. if you can put those in an email for me (that is the times and the machine type speed etc) that would be great | 22:39.59 |
| | Then I will put them in a table for miles | 22:40.08 |
| ray_laptop | cpsi takes 88 seconds to complete the ripping to whatever they do (based on what henrys said, 600 dpi rgb contone) | 22:40.15 |
| mvrhel_laptop | henrys, ray_laptop: are you telling me to do pcl at 600 dpi rgb contone? | 22:40.55 |
| | I was doing CMYK contone out at 600 dpi and 1200dpi. | 22:41.16 |
| | and 4bpp CMYK | 22:41.23 |
| | at 1200dpi | 22:41.27 |
| | with the bitcmyk device | 22:41.33 |
| ray_laptop | mvrhel: no it generated 600 dpi contone out to the HP driver | 22:41.37 |
| mvrhel_laptop | oh ok sorry | 22:41.43 |
| henrys | J11 is just a big con tone rgb image | 22:42.32 |
| mvrhel_laptop | will the 4700 driver generate something better? | 22:42.59 |
| | J11.pcl ran at 0.79 ppm at 1200dpi 4bpp | 22:43.19 |
| ray_laptop | mvrhel: cpsi J10 took 49 seconds, gs to contone 600 dpi rgb takes 6.25 seconds | 22:43.20 |
| mvrhel_laptop | ray_laptop: so we want J9, J11 and J12 | 22:43.38 |
| Robin_Watts | tor7: urk. I guess it depends how huge the API changes are - I got the feeling (though paulgardiner clearly knows more than me) that we were only using v8 in a very simplistic way... | 22:44.07 |
| ray_laptop | mvrhel: cpsi J9 took 30 seconds, gs as above took 3.5 sec | 22:44.22 |
| mvrhel_laptop | that is good | 22:44.29 |
| ray_laptop | yeah, I guess so. | 22:44.38 |
| mvrhel_laptop | ray_laptop: so this is the PS files right? Not the PDF? | 22:44.51 |
| henrys | mvrhel_laptop: I'm not sure, ray_laptop can you install the driver and I'll look. | 22:44.51 |
| | ? | 22:44.58 |
| mvrhel_laptop | let me see if I can install too | 22:45.09 |
| ray_laptop | That's an old Pentium D at 3.4 GHz | 22:45.12 |
| Robin_Watts | OK, so 43% of the CPU time of pdf_reference17.pdf is in fz_paint_span_with_color | 22:45.26 |
| ray_laptop | mvrhel: yes, the ps files created by gs ps2write | 22:45.33 |
| Robin_Watts | and a further 17% is in memset. | 22:45.35 |
| | so that's an obvious hotspot. | 22:45.44 |
| mvrhel_laptop | henrys: so do I want the PCL5 driver? | 22:45.47 |
| | there is a PCL5 one and a PCL6 one | 22:46.12 |
| | and a Postscript one | 22:46.16 |
| henrys | pcl6 for the xl tests and pcl for the pcl ones. | 22:46.34 |
| | for example j12 is not downloading any fonts doing everything with hpgl Beziers - so no cache. Has anyone looked at the PDF? | 22:47.34 |
| | although kanji cache hit rates are low, but still. | 22:48.05 |
| ray_laptop | mvrhel: just for reference to my laptop: 9, 10 and 11 are 1.5, 2.7 and 3.3 respectively | 22:48.15 |
| henrys | mvrhel_laptop: you should be able to tell if you have something better just by the file size. | 22:49.08 |
| mvrhel_laptop | ok | 22:49.27 |
| | pcl5 driver installed | 22:49.37 |
| | and so is pcl6 | 22:49.45 |
| ray_laptop | henrys: was that the PCL file or the PXL file ? | 22:51.15 |
| henrys | PCL | 22:51.43 |
| | haven't looked at any XL yet | 22:51.51 |
| ray_laptop | btw, the ps2write seems to be rendering the fonts as bitmaps (maximal portability PS) | 22:52.06 |
| henrys | I'm also in ROP hell with several of these files. Sometimes that can be optimized at the language level ... | 22:54.20 |
| mvrhel_laptop | hmm stupid driver wont save to a file. it wants me to find a printer even though I said to go to file | 22:54.54 |
| | it wants a destination printer... | 22:55.28 |
| henrys | mvrhel_laptop: how much time do we have for this firedrill? | 22:55.37 |
| mvrhel_laptop | he he | 22:55.44 |
| | exactly | 22:55.46 |
| | well miles wants to get something to them tomorrow | 22:55.55 |
| ray_laptop | henrys: in the original J12 PDF pdf_info.ps reports: | 22:56.05 |
| | Fonts Needed that are not embedded (system fonts required): | 22:56.06 |
| | Century | 22:56.08 |
| mvrhel_laptop | at least we have something from ray comparing cpsi to us | 22:56.09 |
| ray_laptop | FutoGoB101-Bold | 22:56.09 |
| | GothicBBB-Medium | 22:56.11 |
| | MS-Gothic | 22:56.12 |
| | MS-PGothic | 22:56.14 |
| | MS-UIGothic | 22:56.15 |
| | MSPGothic | 22:56.17 |
| | Ryumin-Light | 22:56.18 |
| | Ryumin-Medium | 22:56.20 |
| | ShinGo-Bold | 22:56.21 |
| | ShinGo-Medium | 22:56.23 |
| | ShinGo-regular | 22:56.24 |
| | henrys: so gs is using DroidSansFallback.ttf | 22:57.40 |
| henrys | ray_laptop:funny the windows driver didn't download incremental fonts - do you have don't download fonts checked in the printer driver? | 22:58.36 |
| mvrhel_laptop | ok. so once I gave it the network address to my brother printer it did print to file | 22:58.48 |
| | but I wonder if this file is even color now... | 22:59.11 |
| ray_laptop | mvrhel: did you need J12 as well ? I thought you were just using 9, 10 and 11 | 22:59.16 |
| mvrhel_laptop | J9, J11, and J12 | 22:59.28 |
| | no J10 | 22:59.31 |
| | ray_laptop: ^^ | 22:59.58 |
| | ok so my pcl file is 1/3 of rays | 23:00.15 |
| | let me render it to see what it looks like | 23:00.24 |
| henrys | mvrhel_laptop: put it on casper. I'll have a look at it to make sure it's okay | 23:01.02 |
| mvrhel_laptop | ok thanks | 23:01.09 |
| ray_laptop | henrys: the HP color laserjet CP3505 PCL 5c for TrueType has "substitute with device fonts" selected | 23:02.02 |
| henrys | I'll set up acrobat today on windows so I'm a little more prepared for more of this. | 23:02.11 |
| ray_laptop | that was the default | 23:02.13 |
| mvrhel_laptop | henrys: ghostscript.com/~mvrhel/J9_acrobat.prn | 23:02.50 |
| ray_laptop | mvrhel: which one(s) did you do ? | 23:02.53 |
| mvrhel_laptop | the easy one | 23:03.01 |
| ray_laptop | oh, J9. nm | 23:03.04 |
| henrys | interesting perhaps if you unselect it would do type42 stuff and we'd get something better, not sure. | 23:03.51 |
| ray_laptop | mvrhel: so we probably want to try that one on the Pi to compare with the J9.ps (and PDF) | 23:03.55 |
| mvrhel_laptop | after I get the OK from henrys I will | 23:04.14 |
| ray_laptop | mvrhel: what did you have in your settings ? | 23:04.17 |
| mvrhel_laptop | which settings? | 23:04.24 |
| ray_laptop | in the HP PCL driver | 23:04.35 |
| mvrhel_laptop | the settings are confusing | 23:04.52 |
| | and I am certain that I dont have something right | 23:04.58 |
| ray_laptop | TrueType "download as softfont" | 23:05.02 |
| mvrhel_laptop | I see in the header it says 1 bit / pixel | 23:05.19 |
| | as I feared | 23:05.22 |
| ray_laptop | vs. substitute with device font | 23:05.23 |
| mvrhel_laptop | it is asking me for a printer when I try to print to file | 23:05.29 |
| ray_laptop | what driver is that ? | 23:05.31 |
| mvrhel_laptop | the universal one | 23:05.38 |
| | from the address that henry gave us above | 23:05.46 |
| | once I picked the printer, which is the only one that I have here, then it printed to the file | 23:06.05 |
| | and it is a monochrome laser | 23:06.13 |
| | so it did a 600dpi 1bpp output it appears | 23:06.24 |
| | hence it is a little smaller than yours | 23:06.33 |
| | to me it seems the driver is limited in what you can set up | 23:07.30 |
| | since henry has a 4700, he may be better at generating files | 23:07.46 |
| | Acrobat is pretty easy to install | 23:07.53 |
| | about as easy as the driver was ;) | 23:08.00 |
| ray_laptop | I'm installing the 4700 driver using the link henrys provided. | 23:08.46 |
| henrys | yeah it's monochrome sigh | 23:08.46 |
| ray_laptop | henrys: is the 4700 monochrome ? | 23:09.01 |
| | duh :-( | 23:09.08 |
| mvrhel_laptop | ray_laptop: so did you generate times then with cpsi and gs for J9.PS, J11.PS and J12.PS but no PDF due to CPSI not handling the transparency? | 23:10.07 |
| | just so I understand | 23:10.14 |
| ray_laptop | I didn't do J12, sorry | 23:10.54 |
| | do you want me to ? | 23:11.10 |
| mvrhel_laptop | ok. is it easy for you to add that one in and then send me the results | 23:11.14 |
| | yes please | 23:11.16 |
| ray_laptop | mvrhel: but for 9, 10 and 11 the times are for cpsi and gswin32c at 600 dpi contone. I couldn't run the PDF's with cpsi (except J9) | 23:12.09 |
| mvrhel_laptop | so what we (or Miles) wants at the end of the day is a comparison of gs and Adobe with J9, J11 and J12. If we can do PDF and PS that would be great | 23:12.11 |
| | if we can also do 1200 dpi that would be good | 23:12.38 |
| | if all you can do is J9 for PDF then lets just do that one | 23:13.00 |
| ray_laptop | mvrhel: on that same machine, from PDF gs takes 5, 4.9 and 14.6 seconds. On J9_acrobat.pdf cpsi took 14.6 sec | 23:15.26 |
| | mvrhel: on that same machine, from PDF gs takes 5, 4.9 and 14.6 seconds. On J9_acrobat.pdf cpsi took 36 | 23:15.38 |
| | so gs 5 sec, cpsi 36 sec on J9_acrobat.pdf | 23:16.07 |
| mvrhel_laptop | ray_laptop that is at 600 dpi? | 23:16.51 |
| | cmyk contone | 23:16.55 |
| | and the machine is Pentium D at 3.4 GHz | 23:17.43 |
| ray_laptop | mvrhel: that is RGB contone (same as it appears that cpsi generated) 600 dpi, -dBufferSpace=16m | 23:17.50 |
| mvrhel_laptop | ok | 23:17.55 |
| ray_laptop | mvrhel: yes | 23:17.57 |
| mvrhel_laptop | ok so we wont do 1200 dpi then | 23:18.16 |
| | ray_laptop so the 5, 4.9 and 14.6 times are for gs with J9, J11 and J12 | 23:19.04 |
| ray_laptop | mvrhel: from the PDF original | 23:19.34 |
| mvrhel_laptop | oh ok | 23:19.50 |
| ray_laptop | mvrhel: I don't think I can get cpsi to do 1200 | 23:20.00 |
| mvrhel_laptop | ok that is fine | 23:20.04 |
| | let me just make sure I have the numbers correct for 600dpi | 23:20.15 |
| ray_laptop | the times for gs from the ps2write are above | 23:20.19 |
| | i.e., 3..5 6.2 and 7.2 sec | 23:20.54 |
| mvrhel_laptop | trying to collect them from the above stuff | 23:21.00 |
| | and this is J9, J11 and J12. No J10 | 23:21.07 |
| ray_laptop | that's the gs times for 9 10 and 11. I am going to run 12 in just a bit. | 23:21.45 |
| mvrhel_laptop | ray_laptop I am confused about the two lines you have above. sorry | 23:22.39 |
| | On J9_acrobat.pdf cpsi took 36 and On J9_acrobat.pdf cpsi took 14.6 sec | 23:22.49 |
| | I think I should just wait until you are done | 23:23.27 |
| ray_laptop | mvrhel: cpsi from PDF took 36 sec, and from J9.ps took 30 sec | 23:24.34 |
| | and that's the only PDF that would run | 23:24.53 |
| mvrhel_laptop | right | 23:24.56 |
| ray_laptop | and on J9 gs took 5 sec from PDF and 3.5 from PS | 23:25.25 |
| mvrhel_laptop | ok great | 23:25.39 |
| | so I just need J11 and J12 | 23:26.20 |
| | but I realize that J11.pdf can't run on cpsi | 23:27.02 |
| | can J12 run on cpsi? | 23:27.07 |
| ray_laptop | mvrhel: J11 from PS: cpsi 88 sec, gs 7.2 sec, gs from PDF 14.6 sec | 23:27.44 |
| | mvrhel: I'll find out in a sec. | 23:27.58 |
| mvrhel_laptop | ok thanks | 23:28.01 |
| | ray_laptop: so a question for you also. how were the *.pdf files generated that we have for J9, J11 and J12. I am just wondering in case that comes up | 23:31.53 |
| ray_laptop | using Acrobat from the original files | 23:32.29 |
| mvrhel_laptop | so printing from the application to the Acrobat print dirver? | 23:32.44 |
| | ray_laptop: ^^ | 23:33.32 |
| ray_laptop | mvrhel: yes | 23:35.05 |
| mvrhel_laptop | ray_laptop: ok thank you | 23:35.18 |
| | henrys: so do you think we are dead in the water with respect to showing any PCL results in the near term? | 23:38.14 |
| | perhaps we can get some numbers together by the end of the week? | 23:38.36 |
| | for me to take with us? | 23:38.41 |
| | out meeting is monday | 23:38.47 |
| henrys | II'm working on installing everything. What does ray have from the new driver install? | 23:39.03 |
| mvrhel_laptop | ray_laptop: is cranking J12 now with cpsi vs gs I think | 23:39.23 |
| ray_laptop | henrys: I stopped installing it -- it is monochrome, right ? | 23:39.39 |
| mvrhel_laptop | no the driver will print what ever | 23:39.57 |
| | but it wants a reference printer | 23:40.04 |
| | prior to printing to file | 23:40.13 |
| | at least that is what it is doing to me | 23:40.23 |
| | and I only have a monchrome laser here | 23:40.30 |
| henrys | I'll try to get everything set up. I guess plain acrobat reader should produce the same output right? | 23:40.36 |
| ray_laptop | oh, great. Re-downloading it :_( | 23:40.40 |
| | so what reference printer should I use ? | 23:40.50 |
| mvrhel_laptop | well for me it had to be a physical printer that I had here ray_laptop | 23:41.41 |
| henrys | I'm sure I've run the drivers without printers attached but maybe they have changed something. | 23:41.52 |
| ray_laptop | mvrhel: not really. Just print to FILE: | 23:43.42 |
| | I'm running win 7. maybe they honked something up with 8 | 23:44.16 |
| | henrys: There's only a few ColorLaserJet PCL5 printers on the list | 23:45.56 |
| | mvrhel: J12: from PS: gs 12.5 sec, cpsi 115 sec from PDF: gs 16.2 sec, cpsi 201 sec | 23:46.10 |
| | would be nice to get some timings from cust 801. I think they previously used Adobe | 23:46.59 |
| mvrhel_laptop | ray_laptop: I did select print to file | 23:47.07 |
| | and the it wanted me to select a printer that I had | 23:47.20 |
| | s/the/then/ | 23:47.28 |
| | and which point it would then print to file | 23:47.38 |
| ray_laptop | that download shows me a whole long list of devices | 23:47.50 |
| mvrhel_laptop | hmm | 23:47.58 |
| ray_laptop | mvrhel: I am referring to the Add Printer wizard | 23:48.16 |
| mvrhel_laptop | ray_laptop thanks for the numbers. so J12.pdf ran fine | 23:48.18 |
| | ray_laptop: oh | 23:48.29 |
| henrys | I am close to being set up here if you want to just leave it to me. | 23:48.31 |
| ray_laptop | mvrhel: yes, if you call dog slow "fine" | 23:48.40 |
| | running 12 times slower ! | 23:50.37 |
| mvrhel_laptop | hehe | 23:50.48 |
| | ok so the PS files were generated from ps2write? | 23:51.09 |
| | just so I understand ray_laptop? | 23:51.17 |
| ray_laptop | even with PS, cpsi is 9x slower | 23:51.22 |
| mvrhel_laptop | we need something to make us look good | 23:51.35 |
| ray_laptop | mvrhel: yes. I also converted them using Acrobat 9 "Export as PostScript file" and they were bigger and slightly slower for gs to render | 23:52.12 |
| mvrhel_laptop | ok | 23:52.26 |
| ray_laptop | so I didn't bother with those and cpsi | 23:52.33 |
| mvrhel_laptop | ok sounds good | 23:52.44 |
| ray_laptop | mvrhel: the only thing is that this is so slow, that it is not that credible. Maybe something that Amiable did to honk it up | 23:53.37 |
| mvrhel_laptop | yes | 23:53.49 |
| | it is very lop-sided as I look at it in the table | 23:54.19 |
| | almost rediculous | 23:54.33 |
| ray_laptop | mvrhel: Oh, wait a minute. The CPSI RIP time includes writing to a file. I was using -o nul: | 23:55.29 |
| mvrhel_laptop | oh no | 23:55.38 |
| ray_laptop | let me re-run gs to a file. Sorry | 23:55.52 |
| mvrhel_laptop | ok np | 23:55.59 |
| | glad you caught that | 23:56.41 |
| henrys | yeah I don't remember seeing this dynamoic vs traditional mode bs. | 23:57.27 |
| mvrhel_laptop | right | 23:58.21 |
| | I did the dynamic and then it forces me to pick a printer each time | 23:58.35 |
| | if you do it static, it wants the printer at install time | 23:58.45 |
| | Forward 1 day (to 2013/08/20)>>> | |
IRC Logs