| | <<<Back 1 day (to 2021/03/19) | Fwd 1 day (to 2021/03/21) >>> | 20210320 |
| artifexirc-bot | <Robin_Watts> msirabella: I could be wrong, but I thought the PNGPredictorDecode filter was supposed to implement the handling of PNG Predictors in the decode stream. | 00:22.50 |
| | <Robin_Watts> PNG data can be encoded with 'predictors' to help compress it. Different predictor values change how each value differs from the value that came before. (subtraction is a common one). Accordingly, to make it easy for gs to work with such data, we have a PNGPredictorDecode filter that takes in the PNG data stream with predictor bytes, and gives out a processed stream of raw values (with no predictors). | 00:24.39 |
| | <Robin_Watts> While it's something that helps doing PNG decode, it's certainly not a PNG decoder in its own right. | 00:25.03 |
| msirabella | Ah, it looks like you are right Robin_Watts, I seemed to have skimmed over that. it decodes the "filter" algorithms, not the actual image | 00:25.31 |
| | thank you for your clarification | 00:25.40 |
| artifexirc-bot | <Robin_Watts> emendelson: The (top level) Makefile used with VS is different from that used for other platforms. | 00:26.37 |
| | <Robin_Watts> If you build gs in VS, and extract etc is present, then it will be detected and built in automatically. | 00:27.15 |
| | <Robin_Watts> All you need is to have the source in an 'extract' directory within the ghostpdl tree. | 00:27.42 |
| | <Robin_Watts> The *ix way of working with the configure script does not apply to windows builds. | 00:28.34 |
| emendelson | @Robin_Watts, I'm sorry to have so stupid about this. For the benefit of anyone else who is dim as I am the way to get docxwrite into the executable is to set the environmental variable EXTRACT_DIR to D:\path\to\ghostpdl-9.54.0rc1\extract. What I don't understand is why the build process can't simply find that directory in its default location. And | 02:36.25 |
| | sam_, this explains why my attempt to build in macOS didn't work - I misread the docs as saying that I had to create a directory for the output, or something similar, when it seems that all that's needed is to point to the directory in its default location. | 02:36.25 |
| | Probably everyone else would find the documentation easy to understand, but (if I'm right about this) perhaps it could say that the environment variable should point to the path of the "extract" folder in its default location. It now seems to apply that you might need to create a folder that doesn't already exist in a place where the code could | 02:38.46 |
| | easily know where to look for it. | 02:38.47 |
| | Again, I don't pretend to understand anything at all about this! | 02:38.59 |
| sam_ | ahhhh | 02:44.27 |
| emendelson | "It now seems to imply..." (not "apply") | 02:53.07 |
| artifexirc-bot | <Robin_Watts> emendelson: AIUI, you should not need that environment variable if extract is in its standard position. | 10:04.38 |
| | <Robin_Watts> Based on that path, I assume you're talking about windows. | 10:05.16 |
| | <Robin_Watts> If a build from clean cannot find that code by itself, then that's a problem. | 10:05.54 |
| | <Robin_Watts> Specifically, psi/msvc.mak (the top level makefile called by MSVC) has the following section: | 10:07.47 |
| | <Robin_Watts> `# If $EXTRACT_DIR is unset, and the 'extract' directory exists, | 10:08.03 |
| | <Robin_Watts> # default it to that. | 10:08.03 |
| | <Robin_Watts> !if "$(EXTRACT_DIR)" == "" | 10:08.04 |
| | <Robin_Watts> ! if exist("extract") | 10:08.06 |
| | <Robin_Watts> EXTRACT_DIR=extract | 10:08.07 |
| | <Robin_Watts> ! endif | 10:08.08 |
| | <Robin_Watts> !endif | 10:08.10 |
| | <Robin_Watts> ` | 10:08.11 |
| | <Robin_Watts> So, as long as EXTRACT_DIR isn't set to anything, and there is an extract directory, EXTRACT_DIR will be set for you. | 10:09.07 |
| | <cgdae> emendelson: hi, i'm looking at improving the docs for the `--with-extract-dir` option. I have a patch to improve the description in the output of `autogen.sh --help`, so that it says `--with-extract-dir=EXTRACT_DIR: Build with the specified Extract library. By default we build with Extract automatically if .../ghostpdl/extract exists.`. Would this have helped you, or were you getting information from somewhere other than `autogen.sh | 13:12.29 |
| emendelson | Apologies if these repeat: I don't see these messages in the log, so here they are again: | 13:46.51 |
| | @Robin_Watts and @cgdae: Thanks for jumping in. I got my information from History9.htm, not from anything else. First, in VS2019 running in Windows 10, the docxwrite device is NOT added when I simply build the code as downloaded, with the "extract" folder at the top of the folder tree (NOT moved or otherwise altered by me in any way). If I specify | 13:47.01 |
| | the full path of that extract folder in an environment variable EXTRACT_DIR, then the docxwrite device is created and works very impressively. But I absolutely MUST specify the variable; the build process does not find the folder. - Continued in next... | 13:47.02 |
| | And here's a separate report that has nothing to do with docxwrite. I extracted the source code in macOS Big Sur, and ran .autogen.sh and make - again, I made no changes of any kind, did not set any variables, did not use any parameters for .autogen.sh. The build failed with a series of errors in the tesseract code. Here is the full output: | 13:47.11 |
| | https://www.dropbox.com/s/pr4zyrk95zx79t8/TesseractError.txt?dl=0 | 13:47.11 |
| artifexirc-bot | <cgdae> emendelson: regarding docxwrite, it sounds like the Windows makefile isn't working as it should. Glad that you figured out a work-around, we'll have a look after the weekend. I'm not involved with tesseract so i'll leave that to others. | 14:12.32 |
| | <cgdae> [Actually, the tesseract build errors look like your C++ compiler is too old? - it seems to be tripping up over various relatively modern C++ features such as use of `>>` instead of `> >` in templates.] | 14:15.47 |
| emendelson | @cgdae - Except for installing autoconf, automake, and libtool, I haven't changed anything in macOS Big Sur from the built-in build tools. If I enter gcc --version the terminal returns that this is Apple's clang 12.0.0. I wonder if something changed in Big Sur, because I was always able to build ghostscript in earlier versions. | 14:25.18 |
| chrisl_ | For some reason known only to the developers, the llvm C++ compiler (clang++ - which I delieve is Apple's default) requires -std=c++17 added to the CXXFLAGS | 17:36.06 |
| | Also, it looks like I missed pulling the commit that sorted the VC++ extract directory detection to the release branch. I've done so now. Note that you can give on the nmake command line, doesn't have to be a fully fledged environment variable. | 17:38.06 |
| emendelson | chrisl_ - thank you for that. In VS2019 I tried adding SET EXTRACT_DIR=... && to the nmake command line before I saw your note; that didn't work. Are you saying that I can simply add EXTRACT_DIR=... to the parameters for nmake (in the same way I add MAKEDLL=0 now)? - And I'll experiment with the CXX flag in macOS. - One more question: am I | 18:10.35 |
| | right in thinking that docxwrite will only produce usable results with ghostscript, not with gpcl6..., even though docxwrite is listed as an output device in gpcl6...? | 18:10.36 |
| chrisl_ | Yes, you can just do: nmake -f psi\msvc.mak EXTRACT_DIR=extract ...... | 18:11.38 |
| | Like with ghostscript, how useful docxwrite's output will be from gpcl6 is entirely dependent on the input. *If* the input contains enough information to deduce Unicode code points for the characters, the output will be useful. If not, rather less useful | 18:13.38 |
| | However, it is true that the way PCL often embeds fonts is less helpful in that regard than other languages | 18:14.25 |
| emendelson | chrisl_ Yes, the PCL I've been experimenting with is from WordPerfect for DOS printer drivers, and the best I can get with docxwrite is a few Japanese characters instead of English text. The WP drivers specify the PCL typeface number, the PCL symbol set, and the characters, but nothing more. | 18:28.13 |
| chrisl_ | If it's a standard symbol set, the information should be there, we're probably just not presenting it to the device. And, in all honesty, I'm not sure a) how much work it would take to do that, and b) if it would be worth it. I find it hard to imagine PCL -> docx is an area with much demand | 18:31.00 |
| | Yeh, at the moment, we pay no attention to the symbol set at all. So it *might* be viable to do a better job at that - but it will only help with fonts using a built in symbol set | 18:35.44 |
| | Anyway I'm going to disappear again | 18:37.56 |
| emendelson50 | chrisl_ I completely agree that it's not worth the effort to make PCL->DOCX work correctly! | 19:43.34 |
| emendelson3 | And Bruno Voisin's message on the mailing list solves the problem of building in macOS. Briefly: export CXX="g++ -std=c++17" | 20:03.11 |
| | ./configure | 20:03.12 |
| | make | 20:03.12 |
| | sudo make install | 20:03.13 |
| | <<<Back 1 day (to 2021/03/19) | Forward 1 day (to 2021/03/21)>>> | |
Log of #ghostscript at irc.freenode.net.