| | <<<Back 1 day (to 2018/04/07) | 20180408 |
| sebras | tor8 broke my jbig2dec compilation. :-/ | 05:17.42 |
| | this patch http://git.ghostscript.com/?p=jbig2dec.git;a=commitdiff;h=3cfcf8802109d753769a91d51f22a5f4353fb6d4;hp=c4921544fb9e703930007eab90e458dbf052c6ec makes stdint.h never be include anymore, hence I get compilation error.s | 05:18.13 |
| | in my case HAVE_CONFIG_H is defined and config.h has #define HAVE_STDINT_H 1 which meant that stdint.h used to be included before. | 05:19.24 |
| | previously the HAVE_STDINT_H flag was checked at the end of os_types.h, but now it is only included if HAVE_CONFIG_H is not set. | 05:20.31 |
| | it seems to me that the purpose of the patch is to allow for overriding of stdint.h for system configurations that lack it. | 05:22.13 |
| | woth noting is that I'm building the jbig2dec independent of mupdf and ghostsript. | 05:27.14 |
| | who is messing with my huffman table in jbig2dec?! :-/ | 09:13.28 |
| | turns out that it _wasn't_ a problem with the huffman tables, it was a problem with the byte stream fed into the huffman decoder. | 11:36.08 |
| | the stream had UINT64_MAX bytes available, which stemmed from it being created using a buffer with a claimed -1 number of bytes of data... | 11:36.58 |
| | chrisl: kens: while testing jbig2dec with all the jbig2 bitstreams I now have (>57000!) I found that several caused issues because the datatypes used in JBIG2 are 32 bit unsigned it. and when the values approach 2**32 we run into execution times that appear similar to eternal loops. or slowly allocate more and more memory (e.g. when the number of entries in the symbol dictionary is HUGE). | 15:28.50 |
| | it might be wiser to limit the dimensions of images/symbol bitmaps/halftone bitmaps/etc. to something lower and reasonable. I'm currently playing around with 10000 and it seems to work ok, but might be too conservative. do you have any input on this? | 15:30.38 |
| | I have also added some error hadling and fixed a memory leak or two and implemented the unoptimized versions of non-nomial adaptive pixel positions when decoding generic regions. | 15:31.33 |
| | all of this is in a big mess on sebras/master, but I'll start cleaning this up tomorrow and get it ready for review by Shelley. | 15:32.13 |
| | I'm thinking that maybe we should set up a private repo with all the JBIG2 bitstreams so other people won't have to go through the same hassles that I have. | 15:32.55 |
| | next after that: the luratech decoder. | 15:33.05 |
| simple | is there anyone available to help me track down a problem converting RTF to PS, and gettting an error '/limitcheck in -file-' ? | 17:08.30 |
| | i'm not even sure what the error means, and googling it shows a whole log of limitcheck stuff for things other than -file- | 17:10.38 |
| | going afk for a while, if anyone has any ideas, please leave a message here or in PM, i never go offline | 17:22.50 |
| ray_laptop | simple: since ghostscript doesn't take RTF input, I assume you have PS generated from something else that is throwing a limitcheck when run through gs. You may want to try adding -dESTACKPRINT -dOSTACKPRINT since these give much more info when gs encounters an error that a gs expert can decode. Posting the question on stackoverflow is probably better since the problem is most likely the... | 18:24.05 |
| | ...creator of the PS (the RTF->PS program) | 18:24.06 |
| simple | Hm, I swear I've used GS to convert many RTF to PS. | 21:00.37 |
| ray_laptop | simple: nope. We are working on a gs "output device" to create RTF format from supported input formats, but the input formats are PS+PDF (gs) PCL5/PL/XL (gpcl) XPS/OXPS (gxps) and a few "image" formats, JPEG, PNM, PCX, and PWG via PS lib/view*.ps helper files. | 22:06.25 |
| simple | well, shoot. | 22:07.04 |
| | I've also used Ted to do this conversion.. any other ideas for RTF to PS without using a lame-ass PostScript printer drive on windows? I have to automate thousands of conversions | 22:07.49 |
| ray_laptop | simple: does it have to be PS, or is PDF OK? | 22:08.37 |
| simple | has to be PS, since we concatenate other PS stuff to if before actual printing in the hospitals | 22:09.09 |
| | s/to if/to it/ | 22:09.18 |
| | this method is so archaic, i hate supporting it =/ but if you know the medical field, you understand =/ | 22:10.07 |
| ray_laptop | simple: yes, I worked on NIH s/w grants back in 1974-1976 and some of that software is still available for download (written in MUMPS, now ANSI M) | 22:13.46 |
| simple | oh man, i guess i have it easy then! lol | 22:14.50 |
| ray_laptop | simple: can you use OpenOffice ? | 22:15.16 |
| simple | yes, on windows, probably | 22:15.47 |
| ray_laptop | https://www.openoffice.org/dev_docs/source/sys_reqs_aoo41.html | 22:16.04 |
| simple | i know i tried using it to batch rtf-->pdf and it made spectacularly huge filesize PDFs | 22:16.12 |
| ray_laptop | It may be creating image PDF's (each page is an image wrapped in PDF). | 22:16.43 |
| simple | i don't recall looking at the PDF source, so that's quite possibly true | 22:17.16 |
| | i've used MS Word to do RTF to PDF, using powershell to automate it, and that was fairly ok, but that didn't always work for our systems | 22:18.18 |
| | see, these systems generate PDFs from the PS, and we found out that if you input a PDF into ghostscript, it'll still convert to a PDF output, so we skip a step | 22:18.48 |
| | but that doesn't always work, it seems for our other needs that actually get printed, and not just emailed as a PDF =( | 22:19.07 |
| | our clients provide us with RTF and PDF source documents, so i've been experimenting to find the smallest file PS conversions to ship, and the size is getting out of control... | 22:20.41 |
| | on top of it all, they ship the docs in multiple languages, and Ted isn't handling the unicode variants well | 22:21.55 |
| ray_laptop | There seem to be a few utilities: UnRTF, doc2pdf are a couple | 22:22.24 |
| | but I have no idea what they support, or how well | 22:22.37 |
| simple | i'm pretty sure Ted uses gs as a backend, so that's why i thought gs could do RTF-->PS as well, i guess | 22:22.37 |
| | unrtf sucks badly, it won't actually convert rtf to anything nice | 22:23.01 |
| | not sure i've checked doc2pdf, but i really just need postscript =/ | 22:23.15 |
| ray_laptop | I'm not sure what our other product line (office clone) can do (SmartOffice) | 22:24.33 |
| simple | i can spin up a linux VM to do the conversions too, if that helps | 22:24.39 |
| | bah, gotta run again for a bit, bbl | 22:25.23 |
| ray_laptop | simple: on linux, check Libre Office | 22:28.21 |
| simple | yeah, libre office is basically an openoffice fork, right? | 22:42.35 |
| | i couldn't figure out how to make it do things in a batch, i think | 22:43.36 |
| | maybe i'll just have to write zip/unzip functions into the packager/installer for faster upload/download | 22:52.52 |
| | probably easier, and just deal with the 6gb of files | 22:53.02 |
| ray_laptop | simple: OO has command line mode, It made a decent PDF (that gs can convert to PS) | 22:59.05 |
| | bah, "soffice" (the command line OO) hung, I killed the shell, and now OO won't start (even from the icon) :-( I probably have to reboot | 23:00.11 |
| | Forward 1 day (to 2018/04/09)>>> | |
Log of #ghostscript at irc.freenode.net.