| | <<<Back 1 day (to 2016/10/04) | 20161005 |
| norbertj | kens: hi I'm playing a bit with the ghostpdl (windows visual studio) using the display-device. When I submit pcl files I see that the pl_post_finish_page is called (to press continue), but when submitting postscript files it just continues, there is no time to look at the bitmap. | 13:27.14 |
| kens | Hi Norbert | 13:28.22 |
| | Umm the display device pauses for you to change pages unless you set -dNOPAUSE | 13:29.02 |
| | I'm certain this works, I use it all the time | 13:29.26 |
| | But are you perhaps using your own front-end ? | 13:29.37 |
| chrisl | The gpdl front end passed -dNOPAUSE into Ghostscript | 13:30.07 |
| norbertj | Hi Ken, when replacing with jpeg device I see similar behaviour. Postscript files are immediately converted into jpg bitmaps, but for pcl (and xps I think) it waits for the key-press to continue | 13:30.21 |
| kens | well what Chris just said :-) | 13:30.37 |
| norbertj | No I'm using the default build environment (vs2015 converted) from the 9.20 ghostpdl.SLN | 13:31.00 |
| kens | Can you tell me what the exact command line you are using is ? | 13:31.10 |
| | Because that definitely doesn't happen here | 13:31.22 |
| kens | goes off to check for sure | 13:31.29 |
| norbertj | kens: -r100 -sDEVICE=jpeg -sOutputFile=bla%d.jpg e:/testfiles/ps/a4_gatf.ps e:/testfiles/pcl/colorcir.pxl | 13:31.31 |
| kens | And the executable is named ? | 13:31.54 |
| norbertj | kens: I'm runnign from within the VS2015 devenv (where I compiled the stuff). | 13:31.57 |
| kens | You appear to be executing both PostScript and PXL on the same command line there | 13:32.21 |
| norbertj | executable would be gpdlwin32.exe | 13:32.25 |
| kens | Right, so gpdl as CHris said | 13:32.33 |
| | Which includes -dNOPAUSE in the parameters | 13:32.44 |
| norbertj | kens: yes, ghostpdl supports this (it has all pdls in the pdl_implementation[]). And it only does the wait for the pxl job. | 13:33.20 |
| kens | If you look at ps_impl_allocate_interp_instance() you will see that it includes -dNOPAUSE | 13:33.37 |
| chrisl | I'm suspicious that gpdl doesn't hook the stdio stuff for Ghostscript to get a carriage return to move onto the next page | 13:33.53 |
| kens | So it should not pause for any pages with the display device | 13:34.02 |
| | chrisl that would be a good reason for it to use NOPAUSE | 13:34.23 |
| chrisl | Actually the problem is stranger: the problem is that -dNOPAUSE doesn't reach Ghostscript from the gpdl command line | 13:37.15 |
| kens | Then why does it not pause ? | 13:37.45 |
| | The default behvaiour is to pause | 13:37.52 |
| kens | is rebuilding the executable | 13:38.12 |
| chrisl | Because NOPAUSE is passed from the gpdl front end | 13:38.15 |
| | If you look in gpdl/psi/psitop.c line 122 | 13:38.38 |
| kens | Yes that's the code I refrenced above | 13:38.54 |
| chrisl | Basically, it seems that the only thing you can do at the commend line is set the device, none of the command line parameters are actually passed to Ghostscript | 13:39.32 |
| kens | I can't say I'm terribly surprised, the language switch build is ancient and has not been maintained. | 13:39.56 |
| chrisl | I would describe that as broken from the start | 13:40.40 |
| kens | To be honest I was under the impression that the language switch build has pretty much always been broken | 13:41.11 |
| | gah I just built the wrong thing :-( | 13:41.44 |
| chrisl | Ignoring command line options isn't a great idea, IMHO - doubly so with Ghostscript | 13:42.21 |
| kens | Not disagreeing, jsut saying that I thought this code was so awful that it basically didn't work :-) | 13:43.58 |
| chrisl | There is a ps_end_page_top() - not at all sure how that gets called | 13:44.14 |
| kens | Or if.... | 13:44.33 |
| chrisl | And the answer is: no, it doesn't get called, it seems | 13:46.09 |
| kens | OK if I knock out -dNOPAUSE then it does (as expected) pause between pages, and enter moves onto the next one. So this is some hackiness in the application | 13:46.31 |
| | ps_end_page_top is never called | 13:46.52 |
| chrisl | Which is what I suspected - no plumbing to get it called | 13:47.15 |
| kens | I'm sure you are correct. | 13:47.25 |
| | chrisl there is code for it in zoutputpage, conditionally compiled (!!) on PSI_INCLUDED | 13:49.16 |
| | Seems like my code at least was built without PSI_INCLUDED being defined | 13:49.47 |
| | norbertj : does this answer your question ? | 13:50.22 |
| chrisl | Well, as the code for PCL/PXL/XPS/PS are all built "commonly" now, the PSI_INCLUDED nonsense just isn't going to work | 13:50.38 |
| kens | Well, that's why the plumbing for ps_end_page_top() isn't present then | 13:51.13 |
| | So there's going to have to be some work done to get this supported in a language switch build. | 13:51.45 |
| Harley_ | How do you use /pdf_PDF2PS_matrix and /Rotate described in the pdf_main.ps | 13:53.08 |
| kens | You don't, unless you completely understand PostScript and are prepared to alter the PDF interpreter | 13:53.33 |
| chrisl | Well, the remit for the build reorg was based on doing a new language_switch (hence my opting to change the name). Not prodding the existing ls a bit more | 13:53.50 |
| kens | chrisl not disagreeing, I hadn't realised we'd gone back on that | 13:54.16 |
| | Given how poor the current implementation is, a new one seems like the best solution to me | 13:54.38 |
| chrisl | decisions made at higher pay grade, etc, etc....... | 13:55.41 |
| Harley_ | This command rotates a pdf page to the screen but when using the pdfwriter does not rotate the page "C:\Program Files\gs\gs9.18\bin\gswin64c.exe" -dBATCH -c "(C:/PDF/xxxx.pdf) (r) file runpdfbegin [ 1 ] { << /Orientation 2 >> setpagedevice dup dopdfpages } forall runpdfend" | 13:55.52 |
| kens | Harley_ : meddling with the PDF interpreter is likely to lead to headaches in the long term, not least because you will need to redo any changes every time we do a new release. I wouldn't go there myself, and I'm the maintainer for that code | 13:56.00 |
| norbertj | kens:,chrisl: sorry was in a discussion. Will read the logging and see if it makes sense. | 13:56.11 |
| kens | Harley_ : Have you disabled Auto-rotatiopn ? | 13:56.15 |
| | Don't use the PDF specific operators like that either, those are subject to change without notice | 13:56.42 |
| chrisl | norbertj: is the pause between pages required for you, or is this just a oddity you want to explain? | 13:57.02 |
| Harley_ | Will auto-rotation work when the page is upside down. | 13:57.03 |
| kens | Harley_ : Auto rotation rotates the page until the majority of the text is horizontal | 13:57.24 |
| | And left to right IIRC | 13:57.44 |
| Harley_ | Does that work for pdf's with images | 13:57.53 |
| kens | THat depends what you mean by 'pdfs with images' if the entire content is an image then no, because there is no text. If there is any text present, then yes | 13:58.36 |
| norbertj | chrisl: I was just playing a bit. Seems to me a nice one-in-all pdl to drop jobs on and then get a quick display. | 13:58.49 |
| Harley_ | I'm talking about scanned documents that are now images | 13:59.16 |
| kens | Harley_ : still depends, have the scanned documents been through OCR ? Even if the text is invisible then it will still be counted for rotation | 13:59.49 |
| chrisl | norbertj: We're in the (slow) process of reworking the way gpdl works. If this is important to you, I can do some patching to get it work. But if it's not, I'd rather it was done as part of the "proper" rework | 14:00.43 |
| Harley_ | No OCR | 14:01.04 |
| kens | Well, assuming there is no text, then no auto-rotation will have no efect | 14:01.28 |
| chrisl | norbertj: one of the (several) things that needs resolved is passing command line parameters into Ghostscript, because the current setup just won't work for most Ghostscript users | 14:01.37 |
| norbertj | chrisl: I'm fine the proper rework. No patching for me. Perhaps I will have a look at it too, when at home. | 14:01.45 |
| kens | But you should not be using the PDF-specific routeins the way you are. | 14:01.47 |
| | And setting Orientation isn't a great idea either. | 14:02.20 |
| | That defines the orientation of hte media, not the content | 14:02.34 |
| | So you might end up setting a landscape page, but with portrait content | 14:02.55 |
| norbertj | chrisl:, kens: thanks for the info. Have to go home now. | 14:02.55 |
| Harley_ | I just don't understand how the pdf can be rotated correctly for screen output but when adding -sDEVICE=pdfwrite and a output file the pdf is not rotate. You would think this would work the same. | 14:03.00 |
| chrisl | norbertj: there may be a simple workaround you can use - check the logs later | 14:03.04 |
| norbertj | chrisl: will do. Bye | 14:03.15 |
| kens | Harley_ : aside from the Auto-rotation of pdfwrite, there is no difference in the way iot handles PostScript operations, so anything which works for a rendering device should be the same for pdfwrite. | 14:04.54 |
| chrisl | kens: can you do a test build (probably most easily from the command prompt)? | 14:07.12 |
| kens | A build of what ? | 14:07.31 |
| chrisl | If you can build gpdl with the addition of "XCFLAGS=-DPSI_INCLUDED" to the nmake command line | 14:08.00 |
| kens | Hmm, I can try.... | 14:08.12 |
| ray_laptop | Harley_: note that -dFitPage will rotate and scale pages to fit a fixed page size (a page size set with -gWWWxHHH or other methods) (see doc/Use.htm) | 14:08.12 |
| chrisl | kens: note that you'll need to rebuild *everything* | 14:08.47 |
| kens | :-( | 14:08.54 |
| | Each project individually ? | 14:09.08 |
| Harley_ | I was thinking the same thing but pdfwrite just seems to ignore the orientation change for some reason. Something not working correctly if that is the case. | 14:09.15 |
| chrisl | No, just gpdl, but it will need to recompile all of GS for it | 14:09.29 |
| kens | You probably didn't set -dFIXEDMEDIA, so it gets overridden on each page by the PDF interpreter | 14:09.43 |
| | chrisl OK what's the makefile ? | 14:09.51 |
| ray_laptop | Harley_: I _know_ that pdfwrite works with -dFitPage | 14:10.02 |
| | Harley_: read (and the re-read) doc/Use.htm | 14:10.25 |
| chrisl | kens: so, from the top directory, do: nmake -f psi\msvc.mak DEVSTUDIO= XCFLAGS=-DPSI_INCLUDED (for a 32 bit build) | 14:10.47 |
| | kens: I just want to make sure this works on Windows how I expect | 14:11.08 |
| Harley_ | I'll test commands with -dFitPage and-dFIXEDMEDIA options and see who that works Thanks | 14:11.12 |
| kens | chrisl build is running now | 14:12.21 |
| chrisl | kens: with that, -dNOPAUSE (or its absence) should be honoured | 14:13.22 |
| kens | Hmm, OK I'll try that in a few minutes | 14:13.39 |
| | chrisl that didn't seem to build a gpdlwin*.exe for me | 14:17.12 |
| chrisl | Oh, I meant nmake -f psi\msvc.mak DEVSTUDIO= XCFLAGS=-DPSI_INCLUDED gpdl | 14:17.39 |
| kens | It built gpcl6win32, gswin32, gswin32c and gxpswin32 | 14:17.40 |
| | LOL | 14:17.46 |
| chrisl | You don't need to start afresh this time | 14:17.57 |
| kens | starts again | 14:17.59 |
| | OK that seems to have worked | 14:18.39 |
| chrisl | kens: so it works with/without NOPAUSE? | 14:19.58 |
| kens | No | 14:20.05 |
| | Just tried it without -dNOPAUSE and it does not pause | 14:20.17 |
| | It also givces me an unrecoverable error: stackunderflow in %s_proc_read_continue | 14:20.51 |
| chrisl | Well, it is language_switch..... | 14:21.20 |
| kens | Seems any Postscript file results in that error | 14:21.54 |
| | I could try doing a clean and rebuild if you like | 14:22.08 |
| chrisl | No, I'll fire up Windows and have a look | 14:22.27 |
| kens | I've done a clean and started it off again, it won't tkae long to check | 14:22.46 |
| chrisl | Requiring a special build of Ghostscript is just the kind of sh*t I wanted to get rid of in a revisited language switch | 14:23.27 |
| kens | Yes, absolutely, we should not be doing that | 14:23.57 |
| | clean rebuild makes no difference, still doesn't pause for me | 14:27.46 |
| Harley_ | This commands seems to work for pages that are landscaped with text to the right or text to the left, but when the page is portrait but is upside down the page is not up righted. "C:\Program Files\gs\gs9.20\bin\gswin64c.exe" -dBATCH -dNOPAUSE -dFitPage -dFIXEDMEDIA -sDEVICE=pdfwrite -sOutputFile=C:\PDF\savetest2.pdf -c "(C:/PDF/testfiledown.pdf) (r) file runpdfbegin [ 1 ] { setpagedevice dup dopdfpages } forall runpdfend" | 14:30.12 |
| chrisl | kens: it works for me, on Windows..... | 14:31.04 |
| kens | chrisl maybe I did it wrong | 14:31.13 |
| | Harley_ : If you think you have fouind a bug you may report it as such, however you are abusing the PDF interpreter in an unsupported fashion there. | 14:31.57 |
| chrisl | kens: So, I did (I'm using 64 bit): "nmake -f psi\msvc.mak DEVSTUDIO= WIN64=1 XCFLAGS=-DPSI_INCLUDED gpdl" | 14:33.23 |
| kens | Well, with the exception of WIN64=1 that's the same as mine | 14:33.55 |
| | Oh crap no it isn't | 14:34.23 |
| | I had a lower case d | 14:34.28 |
| chrisl | I guess this is one of those rare case when a Windows application is case sensitive - I love consistency! | 14:35.54 |
| kens | I'm just retrying | 14:36.24 |
| | In case my last comment didn't make it before I got disconnected, it now works as expected, though it still throws an unexpected error on stackunderflow when exiting | 14:41.50 |
| chrisl | Strange, it didn't do that for me, but hey, crap like that is why it needs done properly | 14:42.32 |
| | I wonder why the psitop.c code copies an input PDF to a temp file before passing it to gs....... | 14:43.13 |
| kens | Well I'm getting a 'unrecoverable error: stackunderflow in %s_proc_read_continue' operand stack: -nostringval- unable to close out POSTSCRIPT instance | 14:43.34 |
| | chrisl in case its streamed in off a pipe ? | 14:43.55 |
| chrisl | Oh, it's because through the gpcl6 style "api" we don't have access to the input file, just the "cursor" - god, that's awful :-( | 14:45.45 |
| | norbertj: (for the logs) if you add "XCFLAGS=-DPSI_INCLUDED" to the nmake parameters (either on the command line, or in the nmake options in the project GUI), then gpdl will work with NOPAUSE as you expect. This will *only* work with the gpdl build (Ghostscript on it's own won't build) | 14:49.15 |
| HenryStiles | chrisl: it's the same basically as the run string implementation in gs. | 14:50.04 |
| ray_laptop | chrisl: yeah, and PDF needs seekable input | 14:50.59 |
| chrisl | HenryStiles: it means (again) two different ways of doing the same thing. Plus a potentially large performance hit when interpreting a large PDF file | 14:51.10 |
| Harley_ | Ken_: Seems I have to abuse the PDF interpreter since rotating doesn't not work correclty in all cases. I'm not sure if this is a bug or not, but if a upside down document image should be rotated then this is not working correctly. | 14:52.02 |
| ray_laptop | the plmain (that has access to the file) *could* pass in "(path) run" and so the PDF interpreter would not have to create a tempfile | 14:53.09 |
| chrisl | HenryStiles: the problem boils down to that language_switch was build based on the most limited API we have in there, rather than the most general | 14:53.36 |
| | ray_laptop: it's not the PDF interpreter creating a tempfile, in this case | 14:54.27 |
| ray_laptop | chrisl: oh, it's plmain? so it is using the "run" operator, but just on the tempfile? (it's been a while since I looked at that mess) | 14:55.30 |
| HenryStiles | is norbert really giving this a go? Why would he do that. He has Adobe? Maybe we should switch windows> | 14:55.36 |
| ray_laptop | HenryStiles: good idea | 14:55.57 |
| chrisl | ray_laptop: it's in the gpdl/psi/psitop.c code | 14:56.05 |
| kens | Harley_ : There is nothing you should need to do that requires you to use the low level routines in the PDF interpreter like that | 14:56.20 |
| chrisl | ray_laptop: that was my point: the PDF interpreter already handles a "streamed" PDF by using a temp file - psitop.c implements it's own | 14:57.05 |
| HenryStiles | chrisl: yeah I don't remember why it was done that ways, simply using the run operator should be enough .. | 15:04.21 |
| Harley_ | Ken_: I see -sPageList has been added to 9.20 I was testing with 9.18 | 15:12.35 |
| kens | Harley_ : yes that is now standard across all the interpreters | 15:13.12 |
| Vezz | hi everyone! some mupdf devs online? | 15:30.19 |
| Harley_ | Kens_: I have 3 test files with 5 pages. testfileright.pdf (Landscaped document with text sideways from right to left), testfileleft.pdf (Landscaped document with text sideways from left to right), testfiledown.pdf ( Portrait with texted upside down from bottom to top). Command used "C:\Program Files\gs\gs9.20\bin\gswin64c.exe" -dBATCH -dNOPAUSE -dFitPage -dFIXEDMEDIA -sDEVICE=pdfwrite -sOutputFile=C:\PDF\savetest2.pdf -sPageLi | 15:32.29 |
| | Kens_: Results "testfileright.pdf" is rotated to the left and is correct for portrait style (GOOD), "testfileleft.pdf" is rotated to the left and is portrait style but is now upside down (BAD), "testfiledown.pdf" no change remains the same upside down (BAD). | 15:33.03 |
| Robin_Watts | Vezz didn't hang about, did he? | 15:37.39 |
| kens | Harley_ : I'm a litle busy right now | 15:40.14 |
| | But there is no way I can comment on your PDF files without seeing them | 15:40.55 |
| | ASnd no, I don't mean a screenshot, I mean the actual PDF files | 15:41.14 |
| Harley_ | Kens_: If could tell the PDF Interrupter to rotate the page 90, 180, or 270 that would make things a lot easier. | 15:42.16 |
| kens | There is no provision to do that | 15:43.10 |
| | You can script it with PostScript, that's all | 15:43.23 |
| | You would be amazed at the number of people who say 'if only it did this it would make my life much easier, Ihtink you should add it' | 15:43.48 |
| ray_laptop | Harley_: since images have no information about what is "up" when we rotate we just pick 90 degrees (counter-clockwise). Note that if you add text to a page, the pdfwrite feature that is on by default "AutoRotatePages" will come into play. Read about that in http://www.ghostscript.com/doc/current/VectorDevices.htm#COMMON | 15:57.29 |
| | Harley_: we have some folks that actually print text on the page *under* the image in the orientation they want the image to have so that AutoRotatePage can work | 15:58.44 |
| | Harley_: and even white text suffices (I'm pretty sure). If the page already has text on it, then adding text won't have an effect (pdfwrite selects the "dominant" text orientation) | 16:01.25 |
| | Robin_Watts: I saw your comment about the overflow. But why does the so lib work (does it have that sort of fix that is not in the sources we use?) ? | 16:19.31 |
| Robin_Watts | so lib work? | 16:21.08 |
| | You mean, "why does a build using the shared lib on linux work?" | 16:21.44 |
| | Well, the answer is it doesn't :) | 16:21.55 |
| | It too goes wrong - just differently wrong. | 16:22.06 |
| | We don't get the inversion effect, but we do get corruption at the right hand edge of the image. | 16:22.41 |
| | I suspect that they are using a build with a different idct enabled. | 16:23.00 |
| | (possibly even a different lib is being used under the scenes - like turbojpeg or something). | 16:23.33 |
| ray_laptop | Robin_Watts: actually, according to jpegsnoop, that green stripe is in the data. at MCU[318,65] there is a Lum -1560 with Chr -63 and Chr -994 (which is offset back in the next MCU at the start of the next line) | 16:47.39 |
| Harley_ | I am thinking I can try every command option and I will never get the pdfwriter to orient a page the way I want. Most pdf files we get are correctly oriented to begin with. I just want to be able to correctly rotate a page if the need arises. | 16:48.31 |
| ray_laptop | wore him down ;-) | 16:49.33 |
| | Robin_Watts: I looked at the source of jpegsnoop in their ImgDecode.cpp in CimgDecode::ConvertYCCtoRGBFastFloat(PixelCc &sPix) and it doesn't use the range_limit that our jpeg lib uses (table look up of a masked value where the mask can throw away high bits) | 18:55.54 |
| | Robin_Watts: instead it does: int nValY = (sPix.nPreclipY<-128)?-128:(sPix.nPreclipY>127)?127:sPix.nPreclipY; sPix.nFinalY = nValY + 128; | 18:56.53 |
| Robin_Watts | ray_laptop: That's the color conversion stuff. | 18:57.31 |
| | The problem is occurring in jpeglib in the combined dequant/idct stage. | 18:57.55 |
| | Any changes we made to the YCC2RGB conversion would be too late. | 18:58.25 |
| ray_laptop | since the mask we use is 1023 (1024 entries), centered at 512, any value greater than 16383 will overflow and wrap around. We have (after quant up scaling) 24360 so it wraps around to a low table entry that is 0 rather than 255 | 19:32.24 |
| | Robin_Watts: I suspect that the jpeg file is borked, resulting in the funky quant level, but other readers "clamp" values as jpegsnoopcode does and don't wrap around | 19:33.22 |
| Robin_Watts | ray_laptop: The mask we use where? | 19:52.08 |
| | Any mask we use in the colour conversion is TOO LATE. | 19:52.33 |
| ray_laptop | Robin_Watts: RANGE_MASK is in jdct.h | 19:53.18 |
| | Robin_Watts: the comments in jpeg/jdmaster.c describe that corrupted files need to be protected | 19:53.54 |
| | (search for range_limit) | 19:54.15 |
| | and search for 'bogus' (which is what we have) | 19:55.11 |
| | so the comments indicate that wrap around is possible. Now, I haven't looked to see what is causing the quant value of 6. That may be the root cause. | 19:56.41 |
| Robin_Watts | ray_laptop: right. RANGE_MASK is applied at the end of the dct. | 20:00.22 |
| | s/dct/idct/ | 20:00.29 |
| | The problem is that our values are too large on entry to the DCT. | 20:00.56 |
| | My reading of the spec says there is nothing wrong with large DC coefficients. Indeed, the spec allows for them to be coded. | 20:01.32 |
| | It's just that they are never needed, hence it's rare for them to be used, hence the fact that code doesn't cope with them has gone unnoticed. | 20:02.09 |
| | gotta go. | 20:02.12 |
| HenryStiles | Robin_Watts: I think I might have asked you this before and I've forgotten: is anyone using webnotify with the twiki, I'd like to get notifications when the the webs change but it looks like the plugin isn't set up, entirely possible I'm missing something any of you have watches for the pages? | 20:02.33 |
| | I typed that as you said gotta go, please don't hold up for me. | 20:07.49 |
| Harley_ | I'm having some success flipping an upside down document using the 2 following commands | 20:49.29 |
| | Step 1 rotate to landscape "C:\Program Files\gs\gs9.20\bin\gswin64c.exe" -dBATCH -dNOPAUSE -dDEVICEWIDTHPOINTS=792 -dDEVICEHEIGHTPOINTS=612 -dFitPage -dFIXEDMEDIA -sDEVICE=pdfwrite -sOutputFile=C:\PDF\temprotate.pdf -sPageList=1,3,5 -f C:\PDF\testfiledown.pdf | 20:50.14 |
| | Step 2 "C:\Program Files\gs\gs9.20\bin\gswin64c.exe" -dBATCH -dNOPAUSE -dFitPage -dFIXEDMEDIA -sDEVICE=pdfwrite -sOutputFile=C:\PDF\nowupright.pdf -f C:\PDF\temprotate.pdf | 20:50.53 |
| | Rotating to landscape then back to portrait using those 2 commands flips the document around. The only issue is custom page sizes in a single pdf document. | 20:55.08 |
| Robin_Watts | HenryStiles: I believe WebNotify should work, but it depends whether people do "Quiet Save" or not. | 22:37.04 |
| | Forward 1 day (to 2016/10/06)>>> | |
Log of #ghostscript at irc.freenode.net.