| | <<<Back 1 day (to 2017/04/13) | 20170414 |
| ray_laptop | I also (like Robin_Watts) just upgraded Windows to Creator and am impressed that the Windows bash shell can now run ghostscript built for Windows (gswin64c), although it doesn't run the window version (gswin64.exe) | 05:10.39 |
| | now if they get x11-dev working, we'll have something useful | 05:11.09 |
| BanHammor | Hi! I'm trying to compile ghostscript v9.19 via mipsel cross-compilation, and i'm hitting this error: | 09:30.38 |
| | 'ARCH_SIZEOF_GX_COLOR_INDEX_must_equal_sizeof_GX_COLOR_INDEX_TYPE' is not an integer constant | 09:31.08 |
| kens | Well that's telling you that the 'arch' variable size doesn't match the compile tiem variable size. WHich is not valid for Ghostscript, they must match. | 09:32.08 |
| | Is there a reason you re trying to compile an old version ? | 09:32.27 |
| BanHammor | to be honest, not too much of a reason: i picked up a buildroot recipe for it | 09:34.23 |
| kens | Well we can't help you with something sourced from other than our code. I'd suggest that you start by picking up the current code, then someone here may be able to help you (not me because I don't handle the build system) | 09:35.10 |
| | But I suspect if you want to cross-compile succesfully you will need to do it our way. | 09:35.39 |
| BanHammor | do i need to provide objarch.h methods myself on 9.21? | 09:36.10 |
| | (i mean, not methods. files. my head is not working, sorry) | 09:36.59 |
| kens | In general you need to do some compilation, end execution, on the target platform. That will create files like genarch.h, which you need for further cross-compilation | 09:37.10 |
| | I am not the expert on this I'm afraid. | 09:37.24 |
| | chrisl ping | 09:37.33 |
| chrisl | I'm here | 09:37.54 |
| kens | cross-compilation; not really my thing ;-) | 09:38.07 |
| | I remember that you've made recent changes though, so I'm assuming using current code would be better | 09:38.27 |
| chrisl | For cross compilation, you need to specify both native compiler (CCAUX) and a cross-compiler (CC), and appropriate CFLAGS for each, if required. | 09:40.00 |
| | Something like: https://pastebin.com/qEb85vNV | 09:41.05 |
| | TBH, that's probably more complex than you require for buildroot..... | 09:43.59 |
| | BanHammor: can you find the definition of ARCH_SIZEOF_GX_COLOR_INDEX and compare it to GX_COLOR_INDEX_TYPE which should be in the compiler options in Makefile | 09:46.19 |
| BanHammor | okay, hopefully last question for now: which options turn on building libgs? It seems like this build only builds /usr/bin/gs and dumps a bunch of other stuff into /usr/share | 10:07.22 |
| chrisl | As in the shared lb? | 10:08.11 |
| | s/lb/lib | 10:08.15 |
| BanHammor | yeah | 10:09.11 |
| chrisl | "make so" | 10:09.21 |
| BanHammor | oh, like captain picard :D | 10:25.53 |
| chrisl | Well, close..... | 10:27.47 |
| | I'll be back in a couple of a hours..... | 10:27.48 |
| frostym | Hey quick question, I've been searching around but I can't seem to find a definitive answer. In a DSC header, does the first line *always* start with %!PS-Adobe- or could it be something other than PS-Adobe- after the %!? I figured while I'm rereading all of our EPS files I might as well store the format and %%Creator if it's provided | 14:02.57 |
| | But if it's always PS-Adobe- I'll omit that portion of the string to save space | 14:03.09 |
| kens | If your EPS has a thumbnail then it may contain a header, which may be a bitmap and may be before the %! IIRC | 14:03.33 |
| | But the spec does say I think | 14:03.40 |
| | And for a DSC_conforming file it **MUST** be PS_Adobe-x.y as that defines the conformance level with DSC | 14:04.13 |
| | ie which version of the spec the EPS file conforms to | 14:04.29 |
| | Its not (as some people think) the version of the PostScript language that it conforms to | 14:04.47 |
| | See section 2.1 of the EPS spec where it says that there are 2 required DSC Header comments | 14:05.48 |
| | %!PS-Adobe-3.0 EPSF 3.0 | 14:06.01 |
| | "The first required DSC header comment informs the including application | 14:06.14 |
| | that the file conforms to version 3.0 of the EPSF format as described in this | 14:06.14 |
| | appendix. This is the version comment." | 14:06.14 |
| frostym | Yeah I saw that the %! and BoundingBox are the only two required but others are strongly encouraged. I just wasn't sure if the PS-Adobe- portion was constant or not based on the wording | 14:06.35 |
| kens | So that's 2 versions, 3.0 of the DSWC spec and 3.0 of the EPS spec | 14:06.42 |
| | It has to be PS-Adobe, because its an Adobe spec :-) | 14:07.06 |
| frostym | Makes sense. Is this information only used in applications like Ghostscript for determining how to parse the file? Basically now I'm questioning if storing this data will actually be useful in any way, I incorrectly thought it was the Postscript language version. Not sure why I reached that conclusion yesterday seeing as I did look up EPSF and it clearly doesn't say that | 14:11.58 |
| kens | frostym : any application which handles EPS files needs to parse the header. Its how the application (eg Word, OpenOffice, Quark etc know how to place, scale, rotate the EPS content inside the PostScript that they generate themselves. | 14:13.07 |
| | Its vitally important, must be present and must be correct in order for EPS files to fulfill their purpose. | 14:13.43 |
| frostym | I may not even continue storing this data moving forward but I figured it might be useful to see the %%Creator, Postscript language (and/or EPSF format) for all problematic files I find | 14:13.57 |
| kens | Well it might be interesting, probably not helpful :-) | 14:14.13 |
| frostym | Haha okay, thanks for the help | 14:14.41 |
| StevePhillips | FWIW I can't recall ever getting any useful debugging information out of the DSC header. The good stuff is always buried further down... ;^) | 15:21.13 |
| chrisl | But harder to get at...... | 15:21.56 |
| frostym | Does -dEPSCrop use %%HiResBoundingBox or %%CropBox over %%BoundingBox when available? I have an example EPS (same bad one as before) where the BB is 0 0 109 108 and the other 2 are 0 0 108.3130 107.9415. -dEPSCrop gives me 108x108px which is different than my manually parsed BB | 17:00.39 |
| | Obviously the 109 is rounded wrong and it should be 108 but I don't know which of the 2 is preferred to read instead when available. I'm assuming HiRes? | 17:01.22 |
| | When I rasterize a large res version using gs (-g4199x4161 based on 109x108), my image comes out rotated (https://goo.gl/Glyv8L) too | 17:06.10 |
| kens | it won't use CropBox at all I believe it uses HiResBoundingBox if present, BoundingBox if not | 17:06.45 |
| frostym | Okay thanks | 17:08.25 |
| | Forward 1 day (to 2017/04/15)>>> | |
Log of #ghostscript at irc.freenode.net.