| | <<<Back 1 day (to 2014/10/06) | 2014/10/07 |
| Lolxdnub | Test | 07:14.59 |
| jogux_ | is still knackered. but at least I had first decent nights sleep in about 5 days. | 10:29.03 |
| kens | I slept about 10 hours last night, still feel tired though | 10:31.49 |
| rayjj | morning, all | 13:37.26 |
| kens | Morning rayjj | 13:37.37 |
| pedro_mac | hi rayjj | 13:37.46 |
| rayjj | I'll leave my laptop on while I do the school runs, but may be back a bit late in case we have a meeting | 13:37.58 |
| kens | No meeting | 13:38.08 |
| | henry sent an email | 13:38.14 |
| zlnk | hi, is there someone? | 13:50.48 |
| norbertj | kens: can you explain to me how bisect works? I have a performance drop in pcl between 9.10 and 9.14 and want to find out where it comes from. Can I do this myself? | 13:51.29 |
| kens | norbertj its pretty easy | 13:51.36 |
| | give me a minunte while I get up the man page | 13:51.57 |
| | OK so you start with a revision, eiother good or bad (NB bisect can be confusing in this regard) | 13:52.28 |
| | You start the process with git bisect start | 13:52.39 |
| | declare your current revision as "git bisect good" or "git bisect bad" | 13:53.03 |
| zlnk | I had some difficulties integrating mupdf 1.6 to an android project, are there some tutorials to follow? | 13:53.38 |
| kens | Then check out another revision. Again, declare it either "git bisect good" or "git bisect bad" | 13:53.39 |
| jogux | zlnk: where about did you get stuck? | 13:53.55 |
| | ie. what error are you getting, or what goes wrong? | 13:54.02 |
| zlnk | when I try to compile, it throws that doesnt found the libraries | 13:54.39 |
| henrys | hi norbertj nice to see marten and remco in chicago. We went swimming in the lake quite cold. | 13:54.41 |
| kens | norbertj : then Git will checkout a new revision between those two. You build it and tell Git whether it was "good" or "bad". Git will then repeat hte process. Each time, build the commit it gives you, test it and say "good" or "bad" | 13:54.42 |
| zlnk | I'm trying to update from 1.2 to 1.6 | 13:54.55 |
| norbertj | henrys: lots of goosebumps then. ;) | 13:55.27 |
| kens | norbertj : the tricky bit is that bisect always assumes you are looking for a bug being introduced. So the earliest "good" revision must predcate the "bad" revision. FOr you that's the correct way round, so it should be easy | 13:55.41 |
| henrys | norbertj: we didn't stay in long this year | 13:55.42 |
| | norbertj: marten looks great he's lost a lot of weight since last year. | 13:56.22 |
| kens | norbertj : start with the head code, do "git bisect start" and "git bisect bad" | 13:56.35 |
| jogux | zlnk: when you compile mupdf, or when you compile the your application? (they exact error message may answer that question if you paste it) | 13:56.44 |
| norbertj | henrys: I can imagine. Should be something like the NewYears dive they do here in the Netherlands (either in the see or in a lake). | 13:56.45 |
| kens | then checkout 9.10 (as you say that's OK) and do "git bisect good" | 13:56.49 |
| | Then its just a case of trying it out | 13:57.06 |
| zlnk | when compiling my app, with mupdf I had no problems, | 13:57.47 |
| | the error is this: [armeabi-v7a] Compile thumb : mupdf <= mupdf.c jni/mupdf.c:15:24: fatal error: mupdf/fitz.h: No such file or directory compilation terminated. make: *** [obj/local/armeabi-v7a/objs/mupdf/mupdf.o] Error 1 | 13:58.05 |
| norbertj | kens: just a reminder: checkout 9.10 is done how? with the large number? | 13:58.23 |
| kens | with the commit, but you only need the first 4 or 5 digits | 13:58.38 |
| henrys | norbertj, kens unfortunately there are cycles in performance during that time period which makes git bisect tend to zero in on something you aren't looking for. | 13:58.40 |
| kens | Well, that is certainly awkward | 13:59.00 |
| norbertj | henrys: I know, but 9.10 was ok for this particular file. | 13:59.10 |
| kens | I was going to try a quick check with a profiler to see what was different | 13:59.16 |
| tor8 | nsz: hi. I've read your messages in the IRC log (I've just got back from traveling and am still a bit jet lagged) | 13:59.58 |
| norbertj | I made a BUG for this 695568, but I thought I could try to find it myself too, to get to know how to use bisect. | 13:59.59 |
| tor8 | nsz: thanks for making bug reports in bugzilla, I'll try to fix them both soon | 14:00.20 |
| henrys | norbertj: righ but because of the cycles I would be more inclined to start at 9.10 and jump back say 50 revs ... and continue in that manner, but either way. | 14:00.31 |
| kens | norbertj : I did a "git checkout" 7fcadf to get the 9.10 release | 14:00.49 |
| | henrys 9.10 is OK, 9.14 isn't so jump forward surely ? | 14:01.10 |
| | Or start at 9.14 and go back.... | 14:01.24 |
| norbertj | kens: thanks, will start with that. | 14:01.30 |
| jogux | zlnk: hm. oh. well there is a fitz.h in the mupdf source code.... so the problem is your build is not finding it. I think you need to identify a) where fitz.h is, and b) where your project is looking for it. | 14:01.30 |
| henrys | kens: you yes sorry start at 9.10 | 14:01.50 |
| kens | norbertj : FWIW the current HEAD takes 187 seconds on my PC, debug 32-bit | 14:01.58 |
| tor8 | jogux: zlnk: we rearranged the directory structure in version 1.3 | 14:02.58 |
| | all the header files were moved into a separate 'include' directory | 14:03.13 |
| zlnk | I could see thta | 14:03.16 |
| kens | The job seems to run progressively slower for the first pages, page 116 is especially slow | 14:03.21 |
| henrys | git gheckout ghostscipt-9.10 and like names works fine so you could go a release at a time forward firs | 14:03.32 |
| zlnk | I see jogux, tor8 | 14:03.39 |
| kens | Release at a time seems like a good bet | 14:03.56 |
| tor8 | so if you've got a custom makefile (or project) that builds native code, you'll need to add the appropriate path to -I compiler flag | 14:03.57 |
| norbertj | kens: probably because the are a huge number of macros in it, each page create a number of macros that get never deleted., So searching for a macro could get slower? | 14:04.42 |
| kens | norbertj : that woudl explain a lot certainly | 14:04.56 |
| norbertj | But strange that 9.06 does not show the problem. | 14:04.56 |
| zlnk | Now seems more clear, I was trying to follow this tutorial http://dixitpatel.com/integrating-pdf-in-android-application/ | 14:04.57 |
| kens | hasn't tried 9.06 | 14:05.06 |
| norbertj | kens: current GIT prodbuild gives me 86 secs. | 14:05.16 |
| kens | Hmm | 14:05.25 |
| henrys | norbertj: if this is a slowdown for us in the regular code, I can certainly do it. | 14:05.31 |
| | norbertj: or someone else if it is not pcl. | 14:05.53 |
| kens | Oh yes, well a release build will be faster of course, I was going to use a profiler, so I wanted the suymbols | 14:05.53 |
| | Annoyingly the first bisect I tried is bisecting a merge base. | 14:06.29 |
| norbertj | henrys: it's standard code, I only add a pl_print_usage(&inst, "Finished :"); just before the /* End Main Loop */ comment in plmain.c | 14:06.44 |
| kens | So I think trying to isaloate to a release first might be a better way to start | 14:06.47 |
| henrys | should read his mail. | 14:07.14 |
| kens | norbertj : I forgot to say, when you are finished bisecting, you need to do a "git bisect reset" | 14:07.46 |
| norbertj | kens: yes, I looked up the git bisect documentation. | 14:08.09 |
| kens | Ah, OK then, NP | 14:08.16 |
| norbertj | didn't know it was a git command. | 14:08.23 |
| henrys | okay so there is a bug assigned to me let me know if you want me to look norbertj | 14:08.32 |
| norbertj | henrys: if you could have a look. It's my end-of-day here. And I still have some perfresults to stuff in a report. | 14:11.01 |
| henrys | norbertj: will do sometime today | 14:11.27 |
| kens | 9.12 looks like its quick to ,e | 14:11.40 |
| | It still gets progressivley slower, but it seems faster overall, just waiting till it finishes | 14:12.06 |
| henrys | norbertj: I assume the fast one is correct ;-) | 14:13.06 |
| norbertj | henrys: yes. | 14:13.14 |
| | henrys: note that 9.14 rips empty backsides, which is corrected in 9.15 (conditional ff on pagesideselect). | 14:13.59 |
| kens | oddly 9.12 is not faster | 14:14.27 |
| | I should checkout 9.10 | 14:14.33 |
| norbertj | have to go home. | 14:27.05 |
| kens | henrys for me, 32-bit debug build on WIndows, 9-10 - 182.23, 9.12 - 185, master - 203 seconds | 14:27.06 |
| | So it is slower, but not so much as norbertj sees | 14:27.23 |
| chrisl | kens: the comparison should be with 9.06 | 14:27.48 |
| kens | chrisl norbertj says 9.10 is the same in the bug report | 14:28.03 |
| | same as 9.06 | 14:28.07 |
| jogux | I guess the difference may be less pronounced in a debug build? | 14:28.25 |
| kens | Seems like it is, yes | 14:28.37 |
| | marcos says he's going to bisect it.... | 14:29.06 |
| rayjj | norbertj: you may want to pull in the 'parse done:' message recent change so you can isolate the parse vs render time. (commit 75a183f) | 14:31.08 |
| | that way we can see which is causing the slowdown | 14:31.43 |
| chrisl | So, for 9.06 I see 6m5.913s and current head 7m29.278s | 14:32.59 |
| kens | Not as much as norbert sees, more like what I see by the sound of it | 14:33.27 |
| chrisl | I'll try 9.10 when I get it built | 14:33.46 |
| | That's debug, of course | 14:34.26 |
| kens | I htink norbert was using release builds, your numbers seem close enough to mine, and I'm using a debug build as well | 14:34.48 |
| mvrhel_laptop | good morning | 14:35.11 |
| rayjj | I find it interesting that he is using afs (rather than freetype) | 14:35.20 |
| | I wonder why, and which is faster | 14:35.35 |
| chrisl | That will still be using freetype, iirc | 14:35.42 |
| kens | I think so too | 14:35.57 |
| rayjj | chrisl: I did wonder if afs was still supported | 14:36.04 |
| kens | Its still there, at least partly because pdfwrite uses it :-( | 14:36.25 |
| | Well, the interpreter part of it | 14:36.31 |
| chrisl | rayjj: you can get it with a configure option - or maybe some makefile tweaking.... can't remember right now | 14:36.46 |
| rayjj | chrisl: but not simply with PL_SCALER=afs ? | 14:39.56 |
| chrisl | rayjj: no | 14:40.21 |
| rayjj | chrisl: did that used to work (such as with 9.06) ? | 14:40.56 |
| chrisl | rayjj: with 9.06 afs was the default | 14:41.13 |
| rayjj | was wondering if that was part of the performance | 14:41.21 |
| chrisl | with 9.06, freetype was not an option | 14:41.25 |
| kens | boggles | 14:45.29 |
| | On of the commits I tested is producing fewer pages. | 14:45.45 |
| | So I don't know if that's good or bad :-( | 14:46.04 |
| norbertj | kens: 9.14 produces more pages (empty backsides, because of pageside-selections, whichis fixed in 9.15),but that does not account for the perfdrop. | 14:54.32 |
| kens | I wondered if this was the case. Makes it hard ot know whether its a good or bad bisect though | 14:55.04 |
| norbertj | And I'm indeed compiling with afs (because of 9.06), How do I switch to freetype? B.t.w. I also tested with ufst50/ufst63, and there is the same perfdrop. | 14:55.29 |
| chrisl | norbertj: with 9.06 you can't use freetype | 14:55.57 |
| kens | As chrisl said, you don;t need to do anything with new code, the code uses FreeType now. If you wanted to go back to the Artifex code you would have to do more work. | 14:56.13 |
| norbertj | chris;: I know, that's why I stayed with afs, but how do I switch to freetype for 9.14 eg | 14:56.28 |
| | chrisl: is that PL_SCALAR =freetype? | 14:56.45 |
| chrisl | norbertj: you are using freetype with 9.14 | 14:56.50 |
| norbertj | so PL_SCALAR=afs on 9.14 is actually freetype? | 14:57.08 |
| kens | Setting PL_SCALER=afs will use FreeType in later releases | 14:57.09 |
| chrisl | norbertj: yes | 14:57.15 |
| rayjj | just to be clear, there are supposed to be 117 pages ? | 14:57.28 |
| kens | rayjj : depends on whether you are using 'certain' versions | 14:57.50 |
| rayjj | kens: I'm using HEAD for now | 14:58.08 |
| kens | THen yes, 117 pages I believe is correct | 14:58.18 |
| | Something like that anyway | 14:58.30 |
| norbertj | rayjj: yes, 9.06 and 9.15, but during 9.14 development my duplex support was added, and later on henrys added conditional ff on pageside selection (which corrects again so you get 117 pages). | 14:58.36 |
| kens | The code I'm currently running gets 229 or so | 14:58.52 |
| norbertj | kens: thats because of the duplex support (that wrongly emits empty backsides on a pagesideselect=front). | 14:59.28 |
| kens | Indeed | 14:59.34 |
| | actually 231 it appears | 15:00.05 |
| | 3 more steps after this one.... | 15:00.34 |
| chrisl | So, do the slower versions coincide with the extra pages? | 15:00.43 |
| kens | No | 15:00.50 |
| | My last run was 185 seconds (fast) and had 231 pages | 15:01.05 |
| jogux | tor8: did you want me to try doing an iOS release of mupdf 1.6? | 15:01.40 |
| norbertj | going home now for real. | 15:02.22 |
| tor8 | jogux: yes, please :) | 15:02.38 |
| | it's you or paul, I think, who can do ios releases | 15:02.58 |
| jogux | yeah. I was playing with it on ios 8 anyway (and have more test devices than paul :-) ) | 15:03.21 |
| | I already added iphone6/6+ support to it. | 15:03.28 |
| | tor8 (and anyone else, I have completely forgotten who was actually asking about this at the meeting): paul has some promo codes for SO2, if you wanted to try it on your ipad. | 15:04.04 |
| henrys | kens, chrisl : marcos said he'd bisect it. let's just wait and see what he finds. He has the exe's, he can do it really fast. | 15:04.09 |
| tor8 | jogux: yeah, I saw you had pushed a bunch of ios commits | 15:04.14 |
| rayjj | I observe that the time per page increases steadily (with HEAD) as it progresses. Initially 0.03 sec, increasing to over 3 sec (on my machine the total release build is 165 sec) | 15:04.16 |
| jogux | tor8: paul did review them first, I am following process :-) | 15:04.37 |
| kens | rayjj yes I mentioned that above in the logs. Norbertj theorises that its macros on the pages which are never cleared | 15:04.46 |
| tor8 | jogux: oh, that'd be good. | 15:04.50 |
| chrisl | henrys: what I'm seeing is 9.10 is spending 215 seconds in pl_dict_lookup_entry(), whilst HEAD is spending 260 seconds | 15:05.22 |
| | Also 9.10 spends 25 seconds in pl_dict_undef_purge_synonyms() whilst HEAD spends 32 seconds | 15:06.04 |
| jogux | paulgardiner: one promo code for tor8 then please :-) | 15:06.11 |
| rayjj | kens: chrisl: watching it on the windows display device it paints the signature above Dr. Michael Siegart more and more slowly (otherwise the pages look the same) | 15:06.42 |
| kens | I'd guess tha't the macro | 15:07.09 |
| henrys | well it's good to know we have the entire staff working on this ;-) | 15:07.10 |
| kens | The day after a long haul flight, its about all I'm up to.... | 15:07.41 |
| chrisl | henrys: well, I'm done with it now...... I wanted to check it wasn't obviously a FAPI problem | 15:07.48 |
| paulgardiner | There you go: MWRT7LY4HPJE | 15:07.56 |
| rayjj | that doesn't seem right, however. henrys, you may want to examine the PCL to see what might be causing that (I can see the slowdown even at 90 dpi) | 15:08.33 |
| chrisl | I don't know what PCL uses dictionaries for.... | 15:09.26 |
| kens | Maybe the macro ? | 15:09.37 |
| henrys | rayjj: I'm not looking at it because marcos is going to tell me exactly where it slowed down and then it will take me all of 2 minutes to understand what's hapenned. | 15:09.43 |
| chrisl | admires henrys's optimism | 15:10.43 |
| | kens: but it would be odd if we were suddenly storing more stuff in there with different versions of the source.... | 15:10.50 |
| kens | agreed, certrainly | 15:11.02 |
| rayjj | henrys: well, I'm looking at HEAD, and just observing that it looks "funky" that pages that look so similar are getting slower and slower just painting that one area (the signature image). It goes from what looks ike a 'blit' to very slow line-by-line | 15:11.08 |
| | if we are doing something funky (unexpected) it could be tripping over something that is entirely unoptimized | 15:11.52 |
| | and that can vary due to seemingly unrelated changes | 15:12.16 |
| henrys | rayjj: yes but I'll look at it, it's my problem. | 15:12.24 |
| chrisl | Or I'll look at it if it does turn out to be a font problem..... | 15:13.10 |
| kens | I started doing a bisect just so I could follow along with Norbert, if he was going to do one. I may as well finish now | 15:13.19 |
| henrys | rayjj: you have the boards, chrisl has the library and I have pcl... it's all good. | 15:13.49 |
| rayjj | henrys: I know. I was just doing this while seeing if anything else came up from our non-meeting (since everyone was around anyway). | 15:15.04 |
| henrys | rayjj: are you feeling better? Just a 24 hour thing? | 15:15.39 |
| Robin_Watts | rayjj was ill? I completely missed that. | 15:16.12 |
| | Aeroplane food? | 15:16.17 |
| chrisl | Robin_Watts: that's why Ray stayed Friday night | 15:17.43 |
| henrys | aeroplane - is that a word? | 15:18.07 |
| Robin_Watts | oh. I utterly missed that. | 15:18.12 |
| kens | henrys, yes :-) | 15:18.19 |
| | Its hte proper way to spell airplane | 15:18.34 |
| rayjj | henrys: I've pretty much shaken it off. Getting back to decent weather. I took loads of Zicam and that got me past it | 15:18.57 |
| Robin_Watts | English -Traditional, as opposed to English - Simplified. | 15:19.05 |
| kens | likes that definition | 15:19.20 |
| henrys | some of your spellings make you seem more sophisticated others make you sound like a 5 year old. This would be the latter. | 15:20.20 |
| rayjj | spelling in English can hardly ever be called 'simplified' (compared to something like Spanish). But Chinese simplified isn't all that simple, either | 15:20.35 |
| kens | chrisl bisect threw up c88ded04 as the offending commit for me. | 15:20.57 |
| | henrys the word in English has an o in it. Airplane is American | 15:21.14 |
| Robin_Watts | cannot be held responsible for how words are spelt in proper english. | 15:21.36 |
| henrys | proper english is american we're bigger and have more money | 15:22.09 |
| chrisl | kens: that seems an unlikely candidate..... | 15:22.17 |
| kens | chrisl agreed, but its what came up. I could have made a mistkae with the bisect though. Obvious thing is to try the commit before, and then that one. | 15:22.49 |
| Robin_Watts | henrys: Technically, no. | 15:23.18 |
| | You have a much larger national debt than us :) | 15:23.30 |
| kens | The US has a larger national debt than anyone.... | 15:23.46 |
| Robin_Watts | Yours might be more serviceable than ours though... :) | 15:24.02 |
| | In terms of people speaking "proper" english, we win in numbers of people, because of India, I think. | 15:24.47 |
| kens | I wonder how long before we have an official 'Indian English'..... | 15:26.21 |
| henrys | I suppose you could count the aussies as well don't know how many that adds. | 15:26.59 |
| kens | Nope, Autralian English is separate, like American English | 15:27.21 |
| henrys | not many compared to india | 15:27.22 |
| Robin_Watts | I think we refused the Aussies on the grounds that they say things like "Fair dinkum" and "Dunnie" | 15:27.48 |
| henrys | kens: really but India is proper? | 15:28.09 |
| kens | dunnie is legitimate | 15:28.13 |
| | Its an English word we no longer use (cf dunnikin diver) | 15:28.34 |
| | henrys I believe os yes, because English in India is a second language to most users so is 'fossilised' | 15:29.01 |
| Robin_Watts | India certainly 'was' proper English (they were part of the empire until quite recently). | 15:29.15 |
| kens | Whereas its the native tongue in Australia | 15:29.15 |
| henrys | rayjj: I've never tried zicam maybe I'll give it a go when I feel something coming on. | 15:29.24 |
| Robin_Watts | Technically, English is (or at least was) the official first language in India, I thought. | 15:29.47 |
| kens | Its the official language of government | 15:30.07 |
| | Because there are os many other languages | 15:30.18 |
| Robin_Watts | because it's the language that everyone speaks rather than the language that everyone speaks everyday. | 15:30.27 |
| | Ah, pointless etymological discussions. So much more interesting than the FBS... | 15:31.10 |
| rayjj | henrys: just another data point, then I'll go back to the boards -- with a debug build of HEAD, using -Z: the clist file size remains fairly constant from page 2 to 100 (at 214K), then it *drops* to 175K even though the pages get slower. That points to the parser | 15:31.50 |
| chrisl | kens: backing out that commit from HEAD gave 7m28 (vs 7m29 with it)..... so I don't think that's the culprit | 15:35.08 |
| kens2 | chrisl I'm jsut about to try it. The previous commit was *very* fast at 166 seconds. | 15:35.39 |
| | Testing that commit now to see what it look slike | 15:36.08 |
| | huh both those commits are faster than the current head by a wide margin. They come in at 168 seconds and 166 sedonds, as opposed ot head at 205 | 15:38.52 |
| | So I must have messed up the bisect somewhere | 15:39.05 |
| | well I'm puzzled, head now also gives me 168 seconds. Which is faster than 9.06 | 15:46.19 |
| | Of course this is why I don't try and do real work after a long trip :-) | 15:47.45 |
| jogux | kens2: btw, was reading something earlier about using valgrind's cachegrind plugin to do measurements like these as the result is much more reliable/repeatable than other ways of timing things. | 15:49.20 |
| kens2 | jogux : GS/GhostPCL is consistent enough when faced with an alleged 40% slowdown :-) | 15:49.55 |
| chrisl | jogux: yeh but.... running under valgrind is soooooo slooowwww | 15:50.20 |
| jogux | hehe | 15:50.33 |
| kens2 | And it would mean I would have to boot a Linux VM :-) | 15:50.37 |
| jogux | :) | 15:50.41 |
| chrisl | If Marcos struggles to turn up results, I'll look at it again...... | 15:51.35 |
| rayjj | going for (more) coffee -- bbiab | 16:00.18 |
| kens2 | O I'm going to head off I'm not getting far today. | 16:05.48 |
| | Night all. | 16:05.53 |
| rayjj | hi, paulgardiner | 16:55.31 |
| | paulgardiner: I don't know if you saw the discussion yesterday about the performance hit seen on the nightly regression run with the temp file fix | 16:56.25 |
| | paulgardiner: unless you want to do it, I'll take on implementing a cache for the clist file I/O | 16:57.33 |
| | (there's already a cache in the memfile that I would probably reuse) | 16:57.59 |
| paulgardiner | rayjj: Oh right. I'm easy either way, but I imagine it would be best for you to do it. | 17:01.08 |
| rayjj | paulgardiner: yeah, that way you can continue with your SOT fun :-) | 17:08.23 |
| paulgardiner | yeah, the thought of one moment more away from it fills me with anguish :-) | 17:09.37 |
| | rayjj: do the reader threads ever call clist_fclose with the delete flag set? | 17:15.01 |
| rayjj | paulgardiner: I've opened bug 695575 | 17:26.16 |
| | paulgardiner: yes, they call it with the delete flag set sometimes | 17:26.57 |
| | in gxclthrd.c setup_device_and_mem_for_thread | 17:28.02 |
| | line 148, 149 | 17:28.33 |
| paulgardiner | There's a little tweak I should make then. I seem not to be coping with that correctly. | 17:28.34 |
| rayjj | paulgardiner: it's only with multi-threaded rendering, BTW | 17:28.57 |
| | paulgardiner: or BGPrint | 17:29.07 |
| henrys | bbiaw | 17:29.30 |
| paulgardiner | rayjj: might a reader call clist_fclose with the delete flag set while the writer still has the file open? I'd guess not. | 17:42.12 |
| rayjj | paulgardiner: sorry -- I was not paying attention. This usage is only to get rid of extra temp files created when we open the printer/clist device for a rendering thread. We are going to use the clist files created by the parser, so don't need/want these | 17:48.15 |
| Jt__ | Hello, i have a question would anyone be able to help | 20:48.02 |
| | ? | 20:48.05 |
| Guest51034 | i am using Ghost4j, i am using ps2write my pdf displays landscape and prints landscape however when i convert using ps2write the PS File does not print landscape...any suggestions? | 20:49.41 |
| | is any one able to help? | 20:52.25 |
| henrys | I wasn't able to understand your question. you say you are using ps2write in both cases. | 20:53.20 |
| Guest51034 | sorry, yes i am using ps2write | 20:53.47 |
| | i have a pdf that is landscape mode and i convert to ps | 20:53.58 |
| | if i print that PS, it prints portrait | 20:54.12 |
| | i have to use version 8.70 as i am using oel5 hope this makes sense | 20:55.05 |
| henrys | oh well you need to reproduce problems in a reasonably current release. preferably the latest. let us know if you can do that then we'll have a look -http://www.ghostscript.com will guide you to a release. | 20:57.18 |
| Guest51034 | ok, guess im just looking for an appropriate command to make sure the PDF gets converted into a PS in landscape mode, are you able to give me the relevant command. i have tried several but to no avail | 20:58.32 |
| | if not, dont worry will go away and investigate | 20:58.53 |
| henrys | Guest51034: hard for me to say off the top of my head what is going, ken sharp will be here during work hours GMT and he's very used to fielding these questions from users and might know right away. | 21:00.14 |
| Guest51034 | Ok, i will revisit then | 21:00.35 |
| | many thanks for your help | 21:00.40 |
| henrys | Guest51034: sure | 21:00.47 |
| rayjj | Guest51034: (for the logs) the issue is probably that yoy need -dAutoRotatePages=false | 22:05.00 |
| | If the text on a page is portrait (or there is no text, as actual text in the PDF as many scanners produce) then AutoRotatePages defaults to portrait. Please see: http://www.ghostscript.com/doc/9.14/Ps2pdf.htm#Orientation (BTW, that is -dAutoRotatePages=/None | 22:08.27 |
| | (not false) | 22:08.34 |
| | chrisl_away: (for the logs) How about a http://www.ghostscript.com/doc/current/... (link to the latest release) | 22:09.24 |
| rayjj | has trouble remembering all of the pdfwrite option syntax and should check the docs | 22:10.43 |
| chrisl_away | rayjj: (for the logs) http://ghostscript.com/doc/current *does* contain the latest release docs | 22:37.34 |
| | Forward 1 day (to 2014/10/08)>>> | |
IRC Logs