Re: [ft-devel] Z/OS status
BTW, how are PS fonts handled on z/OS? Or, more general, how is PostScript handled on z/OS? Since PS is plain text normally, it could be EBCDIC also. And another follow-up: What about BDF and PCF? The former are pure text files, and the latter could be different too (in case they are based on EBCDIC text files). Do you know a document which covers fonts on z/OS and how they are stored and processed? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Z/OS status
Is there a possibility for the z/OS compiler to select the encoding of an input file? This would be the easiest solution. There is, but this doesn't completely work. It only covers cases where they may be string literals in the code which are expected to be in ascii. It still leaves open the possibility of there being algorithmic problems (there are, for example, functions called things like utf8_to_ascii and so on -- clearly they are broken on an EBCDIC system, regardless of the code page you use to compile the code). I don't find this a satisfactory solution. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Z/OS status
I've never actually run the XWindows system on Z/OS [...] Oops, this answers the question in my previous mail. Still wondering what kind of fonts are used for the z/OS graphics display... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Z/OS status
What's the status of FreeType on z/os? This is EBCDIC, right? I believe that is the reason of your problems. All FreeType source files which contain character constants like 'A', must preserve those constants as ASCII values, because FreeType always opens files in binary mode. In particular, TrueType tags must be handled as such, which currently isn't the case. Is there a possibility for the z/OS compiler to select the encoding of an input file? This would be the easiest solution. Otherwise I could also imagine that we provide a script which converts strings and character constants to the right (ASCII) value, this is, replacing everything with character code values using the \x notation. Any ideas what might be wrong, or how I can get further with this? In case z/OS is no longer EBCDIC, please call your test program with FT2_DEBUG=any:7 your_program your_program.log Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Z/OS status
In partial answer to my own question, I modified include/freetype/tttags.h as aluded to in a previous post, to change all of the lines like #define TTAG_avar FT_MAKE_TAG( 'a', 'v', 'a', 'r' ) to lines like #define TTAG_avar FT_MAKE_TAG( 0x61, 0x76, 0x61, 0x72 ) So my guess was correct. I can send a new version of the tttags.h file for inclusion in CVS if required. Mhmm, as mentioned in the other mail, this isn't an elegant solution since it uglifies the source code. I'm currently thinking of tagging all affected strings with a no-op macro, say, ASCII(This is a string which must stay in ASCII) and replacing all character constants with C_A, C_B, etc.: #define C_A 0x41 #define C_B 0x42 ... After this has been done, a small script just needs to catch those tags. BTW, how are PS fonts handled on z/OS? Or, more general, how is PostScript handled on z/OS? Since PS is plain text normally, it could be EBCDIC also. I highly suspect that my naïve EBCDIC approach in file src/psaux/psconv.c doesn't work correctly... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
