From: Per P. <per...@ma...> - 2005-05-10 19:54:53
Attachments:
plcore.patch
|
Hi Hazen, here is a patch for plcore.c that handles utf8->ucs4 in pl_text without relying on libunicode. This fixes x24c (peace flag), as long as the selected font supports the glyphs. I used Arial Unicode MS for all tests. The patch is not tied to Mac OS X in any way (except assuming that an int is 32 bits...) and could be used as the default routine. I couldn't find any other uses of libunicode calls in plcore.c (didn't look very hard) so that dependency could be removed from plcore using this code instead. That way, the #ifdefs would go away completely which is IMHO a Good Thing. PS. I'm cc-ing the list in case anyone has questions about the patch. /Per -------- Per Persson, Ph.D. Applied Signal Processing Resume, contact info and more: http://homepage.mac.com/persquare |
From: Alan W. I. <ir...@be...> - 2005-05-11 04:26:25
|
On 2005-05-10 19:01-0700 hba...@ma... wrote: > > Per has been struggling to get the AquaTerm driver to properly display > example 24, which it should handle now that it is unicode enabled. This > was difficult because it looks like PLplot doesn't always use UCS4 for > text. Was it incorrect to assume that all PLplot text that is sent to > a driver is UCS4? Is there some way to tell otherwise? Since the AquaTerm > driver does its own unicode conversion (i.e. UCS4 -> UTF8) it gets > very confused if the text is already UTF8. The plplot core has two font systems. See http://plplot.sourceforge.net/docbook-manual/plplot-html-5.5.2/characters.html for details. If you want the unicode fonts which are indexed by UCS4, then for the ps.c and gd.c devices you specify the driver option text=1 (which occurs by default) which in turn sets pls->dev_text = 1; /* want to draw text */ pls->dev_unicode = 1; /* want unicode */ If your device sets those two flags permanently, then you will never get the Hershey fonts. Instead, when text needs to be plotted your driver's escape function will be called with an op code of PLESC_HAS_TEXT, and a pointer ptr which points to an EscText struct (see include plplotP.h for a definition of EscText) which gives you the information necessary to access the array of UCS4 indices (with the occasional FCI mixed in the array) corresponding to the text. When unicode fonts are enabled (see above flags), there is no UTF8 whatsoever allowed inside Plplot except where unicode_get_utf8 translates external UTF8 strings into UCS4. I also remark for the sake of completeness that ascii characters (as opposed to arrays of UCS4 indices representing text) are allowed into PLplot for Hershey fonts, but that is not the case we are discussing. HTH. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Thomas J. D. <to...@fi...> - 2005-05-12 17:34:35
Attachments:
plcore.c.patch
|
Hi, I understand what Per is on about, and it's important. I have been struggling with x24c as well. The problem is that our unicode implementation currently requires that you have libunicode installed. If you don't have libunicode (like on my system presently), then a vital section of code in plcore.c that translates utf8 to ucs4 does not get executed. ACK!! Per has provided us with a nice bit of code that allows us to avoid libunicode altogether. I have made a few adjustments to it, and have removed the unnecessary section invoking libunicode from plcore.c. Look for the block beginning with the words "Per Persson". Note that I changed the indentation for all of plP_text because I just couldn't deal with it anymore. ;^) I have tested the results for many examples (including x24c) on the png and gcw drivers, and they appear to be good. I would like to hear if others accept this patch. If so, then maybe we can apply it for tomorrow's release. It fixes a *nasty* bug. Please advise. Cheers, Tom -- --- plcore.c 2005-05-12 14:14:24.000000000 -0300 +++ plcore.c.new 2005-05-12 14:05:21.000000000 -0300 @@ -470,262 +470,307 @@ PLINT refx, PLINT refy, const char *string) { - if (plsc->dev_text) { /* Does the device render it's own text ? */ - EscText args; - short len=0; - char skip; - unsigned short i,j, k; - PLUNICODE code; - char esc; - int idx; - - args.base = base; - args.just = just; - args.xform = xform; - args.x = x; - args.y = y; - args.refx = refx; - args.refy = refy; - args.string = string; - - if (plsc->dev_unicode) { /* Does the device also understand unicode? */ - PLINT ig; - PLUNICODE fci, fcisave; - unsigned char hexdigit, hexpower; - - PLINT clpxmi, clpxma, clpymi, clpyma; - - /* Now process the text string */ - - if (string!=NULL) { /* If the string isn't blank, then we will - * continue - */ - - len=strlen(string); /* this length is only used in the loop - * counter, we will work out the length of - * the unicode string as we go */ - plgesc(&esc); + if (plsc->dev_text) { /* Does the device render it's own text ? */ + EscText args; + short len=0; + char skip; + unsigned short i,j, k; + PLUNICODE code; + char esc; + int idx; + + args.base = base; + args.just = just; + args.xform = xform; + args.x = x; + args.y = y; + args.refx = refx; + args.refy = refy; + args.string = string; + + if (plsc->dev_unicode) { /* Does the device also understand unicode? */ + PLINT ig; + PLUNICODE fci, fcisave; + unsigned char hexdigit, hexpower; + + PLINT clpxmi, clpxma, clpymi, clpyma; + + /* Now process the text string */ + + if (string!=NULL) { /* If the string isn't blank, then we will + * continue + */ + + len=strlen(string); /* this length is only used in the loop + * counter, we will work out the length of + * the unicode string as we go */ + plgesc(&esc); - /* At this stage we will do some translations into unicode, like - * conversion to Greek , and will save other translations such as - * superscript for the driver to do later on. As we move through - * the string and do the translations, we will get - * rid of the esc character sequence, just replacing it with - * unicode. - */ + /* At this stage we will do some translations into unicode, like + * conversion to Greek , and will save other translations such as + * superscript for the driver to do later on. As we move through + * the string and do the translations, we will get + * rid of the esc character sequence, just replacing it with + * unicode. + */ - /* Obtain FCI (font characterization integer) for start of - * string. */ - plgfci(&fci); - for (j=i=0;i<len;i++) { /* Walk through the string, and convert - * some stuff to unicode on the fly */ - skip=0; + /* Obtain FCI (font characterization integer) for start of + * string. */ + plgfci(&fci); + for (j=i=0;i<len;i++) { /* Walk through the string, and convert + * some stuff to unicode on the fly */ + skip=0; - if (string[i]==esc) { - switch(string[i+1]) { - case '(': /* hershey code */ - i+=2+text2num(&string[i+2],')',&code); - idx=plhershey2unicode(code); - /* momentarily switch to symbol font. */ - fcisave = fci; - plP_hex2fci(PL_FCI_SYMBOL, PL_FCI_FAMILY, &fci); - unicode_buffer[j++]= fci; - unicode_buffer[j++] = \ - (PLUNICODE)hershey_to_unicode_lookup_table[idx].Unicode; - - /* if unicode_buffer[j-1] corresponds to the escape - * character must unescape it by appending one more. - * This will probably always be necessary since it is - * likely unicode_buffer will always have to contain - * escape characters that are interpreted by the device - * driver. - */ - if (unicode_buffer[j-1]==esc) unicode_buffer[j++]=esc; - fci = fcisave; - unicode_buffer[j]= fci; - skip=1; - break; + if (string[i]==esc) { + switch(string[i+1]) { + case '(': /* hershey code */ + i+=2+text2num(&string[i+2],')',&code); + idx=plhershey2unicode(code); + /* momentarily switch to symbol font. */ + fcisave = fci; + plP_hex2fci(PL_FCI_SYMBOL, PL_FCI_FAMILY, &fci); + unicode_buffer[j++]= fci; + unicode_buffer[j++] = \ + (PLUNICODE)hershey_to_unicode_lookup_table[idx].Unicode; + + /* if unicode_buffer[j-1] corresponds to the escape + * character must unescape it by appending one more. + * This will probably always be necessary since it is + * likely unicode_buffer will always have to contain + * escape characters that are interpreted by the device + * driver. + */ + if (unicode_buffer[j-1]==esc) unicode_buffer[j++]=esc; + fci = fcisave; + unicode_buffer[j]= fci; + skip=1; + break; - case '[': /* unicode */ - i+=2+text2num(&string[i+2],']',&code); - /* momentarily switch to symbol font. */ - fcisave = fci; - plP_hex2fci(PL_FCI_SYMBOL, PL_FCI_FAMILY, &fci); - unicode_buffer[j++]= fci; - unicode_buffer[j++]=code; - /* if unicode_buffer[j-1] corresponds to the escape - * character must unescape it by appending one more. - * This will probably always be necessary since it is - * likely unicode_buffer will always have to contain - * escape characters that are interpreted by the device - * driver. - */ - if (unicode_buffer[j-1]==esc) unicode_buffer[j++]=esc; - fci = fcisave; - unicode_buffer[j] = fci; - skip=1; - break; + case '[': /* unicode */ + i+=2+text2num(&string[i+2],']',&code); + /* momentarily switch to symbol font. */ + fcisave = fci; + plP_hex2fci(PL_FCI_SYMBOL, PL_FCI_FAMILY, &fci); + unicode_buffer[j++]= fci; + unicode_buffer[j++]=code; + /* if unicode_buffer[j-1] corresponds to the escape + * character must unescape it by appending one more. + * This will probably always be necessary since it is + * likely unicode_buffer will always have to contain + * escape characters that are interpreted by the device + * driver. + */ + if (unicode_buffer[j-1]==esc) unicode_buffer[j++]=esc; + fci = fcisave; + unicode_buffer[j] = fci; + skip=1; + break; - case '<': /* change font*/ - i+=2; - if ('0' <= string[i] && string[i] <= '9' ) { - i+=text2num(&string[i],'>', &code); - if (code & PL_FCI_MARK) { - /* code is a complete FCI (font characterization - * integer): change FCI to this value. - */ - fci = code; - unicode_buffer[j]=fci; - skip=1; - } - else { - /* code is not complete FCI. Change - * FCI with hex power in rightmost hex - * digit and hex digit value in second rightmost - * hex digit. - */ - hexdigit = (code >> 4) & PL_FCI_HEXDIGIT_MASK; - hexpower = code & PL_FCI_HEXPOWER_MASK; - plP_hex2fci(hexdigit, hexpower, &fci); - unicode_buffer[j]=fci; - skip=1; - } - } + case '<': /* change font*/ + i+=2; + if ('0' <= string[i] && string[i] <= '9' ) { + i+=text2num(&string[i],'>', &code); + if (code & PL_FCI_MARK) { + /* code is a complete FCI (font characterization + * integer): change FCI to this value. + */ + fci = code; + unicode_buffer[j]=fci; + skip=1; + } + else { + /* code is not complete FCI. Change + * FCI with hex power in rightmost hex + * digit and hex digit value in second rightmost + * hex digit. + */ + hexdigit = (code >> 4) & PL_FCI_HEXDIGIT_MASK; + hexpower = code & PL_FCI_HEXPOWER_MASK; + plP_hex2fci(hexdigit, hexpower, &fci); + unicode_buffer[j]=fci; + skip=1; + } + } - else { - /* align i on "<" because that is what text2fci - * expects. */ - i--; - i+=text2fci(&string[i], &hexdigit, &hexpower); - if (hexpower < 7) { - plP_hex2fci(hexdigit, hexpower, &fci); - unicode_buffer[j]=fci; - skip=1; - } - } - break; + else { + /* align i on "<" because that is what text2fci + * expects. */ + i--; + i+=text2fci(&string[i], &hexdigit, &hexpower); + if (hexpower < 7) { + plP_hex2fci(hexdigit, hexpower, &fci); + unicode_buffer[j]=fci; + skip=1; + } + } + break; - case 'f': /* Deprecated Hershey-style font change*/ - case 'F': /* Deprecated Hershey-style font change*/ - /* We implement an approximate response here so that - * reasonable results are obtained for unicode fonts, - * but this method is deprecated and the #<nnn> or - * #<command string> methods should be used instead - * to change unicode fonts in mid-string. - */ - fci = PL_FCI_MARK; - if (string[i+2] == 'n') { - /* medium, upright, sans-serif */ - plP_hex2fci(PL_FCI_SANS, PL_FCI_FAMILY, &fci); - } else if (string[i+2] == 'r') { - /* medium, upright, serif */ - plP_hex2fci(PL_FCI_SERIF, PL_FCI_FAMILY, &fci); - } else if (string[i+2] == 'i') { - /* medium, italic, serif */ - plP_hex2fci(PL_FCI_ITALIC, PL_FCI_STYLE, &fci); - plP_hex2fci(PL_FCI_SERIF, PL_FCI_FAMILY, &fci); - } else if (string[i+2] == 's') { - /* medium, upright, script */ - plP_hex2fci(PL_FCI_SCRIPT, PL_FCI_FAMILY, &fci); - } else - fci = PL_FCI_IMPOSSIBLE; + case 'f': /* Deprecated Hershey-style font change*/ + case 'F': /* Deprecated Hershey-style font change*/ + /* We implement an approximate response here so that + * reasonable results are obtained for unicode fonts, + * but this method is deprecated and the #<nnn> or + * #<command string> methods should be used instead + * to change unicode fonts in mid-string. + */ + fci = PL_FCI_MARK; + if (string[i+2] == 'n') { + /* medium, upright, sans-serif */ + plP_hex2fci(PL_FCI_SANS, PL_FCI_FAMILY, &fci); + } else if (string[i+2] == 'r') { + /* medium, upright, serif */ + plP_hex2fci(PL_FCI_SERIF, PL_FCI_FAMILY, &fci); + } else if (string[i+2] == 'i') { + /* medium, italic, serif */ + plP_hex2fci(PL_FCI_ITALIC, PL_FCI_STYLE, &fci); + plP_hex2fci(PL_FCI_SERIF, PL_FCI_FAMILY, &fci); + } else if (string[i+2] == 's') { + /* medium, upright, script */ + plP_hex2fci(PL_FCI_SCRIPT, PL_FCI_FAMILY, &fci); + } else + fci = PL_FCI_IMPOSSIBLE; - if (fci != PL_FCI_IMPOSSIBLE){ - i+=2; - unicode_buffer[j] = fci; - skip = 1; - } - break; + if (fci != PL_FCI_IMPOSSIBLE){ + i+=2; + unicode_buffer[j] = fci; + skip = 1; + } + break; - case 'g': /* Greek font */ - case 'G': /* Greek font */ - /* Get the index in the lookup table - * 527 = upper case alpha displacement in Hershey Table - * 627 = lower case alpha displacement in Hershey Table - */ - /* momentarily switch to symbol font. */ - fcisave = fci; - plP_hex2fci(PL_FCI_SYMBOL, PL_FCI_FAMILY, &fci); - unicode_buffer[j++]= fci; - ig = plP_strpos(plP_greek_mnemonic, string[i+2]); - if (ig >= 0) { - if (ig >= 24) - ig = ig + 100 - 24; - idx=plhershey2unicode(ig+527); - unicode_buffer[j++] = \ - (PLUNICODE)hershey_to_unicode_lookup_table[idx].Unicode; - i+=2; - skip=1; /* skip is set if we have copied something - * into the unicode table */ - } - else { - /* Use "unknown" unicode character if string[i+2] - * is not in the Greek array.*/ - unicode_buffer[j++]=(PLUNICODE)0x00; - i+=2; - skip=1; /* skip is set if we have copied something - * into the unicode table */ - } - fci = fcisave; - unicode_buffer[j]= fci; - break; + case 'g': /* Greek font */ + case 'G': /* Greek font */ + /* Get the index in the lookup table + * 527 = upper case alpha displacement in Hershey Table + * 627 = lower case alpha displacement in Hershey Table + */ + /* momentarily switch to symbol font. */ + fcisave = fci; + plP_hex2fci(PL_FCI_SYMBOL, PL_FCI_FAMILY, &fci); + unicode_buffer[j++]= fci; + ig = plP_strpos(plP_greek_mnemonic, string[i+2]); + if (ig >= 0) { + if (ig >= 24) + ig = ig + 100 - 24; + idx=plhershey2unicode(ig+527); + unicode_buffer[j++] = \ + (PLUNICODE)hershey_to_unicode_lookup_table[idx].Unicode; + i+=2; + skip=1; /* skip is set if we have copied something + * into the unicode table */ + } + else { + /* Use "unknown" unicode character if string[i+2] + * is not in the Greek array.*/ + unicode_buffer[j++]=(PLUNICODE)0x00; + i+=2; + skip=1; /* skip is set if we have copied something + * into the unicode table */ + } + fci = fcisave; + unicode_buffer[j]= fci; + break; - } - } + } + } - if (skip==0) { -#ifdef HAVE_LIBUNICODE - unicode_char_t unichar; - char* ptr = - unicode_get_utf8 (string + i, &unichar); - if (ptr == NULL) { - char buf[80]; - strncpy (buf, string, 30); - sprintf (buf, "UTF-8 string is malformed: %s%s", - buf, strlen (string) > 30 ? "[...]" : ""); - plabort (buf); - } - unicode_buffer [j] = (PLUNICODE) unichar; - i += ptr - (string + i) - 1; -#else - unicode_buffer[j]=string[i]; -#endif - /* Search for escesc (an unescaped escape) in the input - * string and adjust unicode_buffer accordingly). - */ - if (unicode_buffer[j] == esc && string[i+1] == esc) { - i++; - unicode_buffer[++j] = esc; - } - } - j++; + /* This section does utf8 to ucs4 conversion without + * using libunicode. Contributed by Per Persson. + */ + if (skip==0) { + PLUNICODE unichar; + char tmp; + char *ptr = (char *)string + i; + int isFirst = 1; + int cnt; + + do { + /* Get next character in string */ + tmp = *ptr++; + if (isFirst) { /* First char in UTF8 sequence */ + isFirst = 0; + /* Determine length of sequence */ + if ((unsigned char)(tmp&0x80)==0x00) { /* single char */ + unichar = (PLUNICODE)tmp & 0x7F; + cnt = 0; + } else if((unsigned char)(tmp&0xE0)==0xC0) { /* 2 chars */ + unichar = (PLUNICODE)(tmp & 0x1F); + cnt = 1; + } else if((unsigned char)(tmp&0xF0)==0xE0) { /* 3 chars */ + unichar = (PLUNICODE)(tmp & 0x0F); + cnt = 2; + } else if((unsigned char)(tmp&0xF8)==0xF0) { /* 4 chars */ + unichar = (PLUNICODE)(tmp & 0x07); + cnt = 3; + } else if((unsigned char)(tmp&0xFC)==0xF8) { /* 5 chars */ + unichar = (PLUNICODE)(tmp & 0x03); + cnt = 4; + } else if((unsigned char)(tmp&0xFE)==0xFC) { /* 6 chars */ + unichar = (PLUNICODE)(tmp & 0x01); + cnt = 5; + } else { /* Malformed */ + ptr = NULL; + cnt = 0; + } + } + else { /* Subsequent char in UTF8 sequence */ + if ((unsigned char)(tmp & 0xC0) == 0x80) { + unichar = (unichar << 6) | ((PLUNICODE)(tmp & 0x3F)); + cnt--; + } + else { /* Malformed */ + ptr = NULL; + cnt = 0; + } + } + } while (cnt > 0); + if (ptr == NULL) { + char buf[80]; + strncpy (buf, string, 30); + sprintf (buf, "UTF-8 string is malformed: %s%s", + buf, strlen (string) > 30 ? "[...]" : ""); + plabort (buf); } - if (j > 0) { - args.unicode_array_len=j; /* Much easier to set the length than - * work it out later :-) */ - args.unicode_array=&unicode_buffer[0]; /* Get address of the - * unicode buffer (even - * though it is - * currently static) */ - } else - /* Don't print anything, if there is no unicode to print! */ - return; - } - } + unicode_buffer [j] = (PLUNICODE) unichar; + i = ptr - string - 1; + + + /* Search for escesc (an unescaped escape) in the input + * string and adjust unicode_buffer accordingly). + */ + if (unicode_buffer[j] == esc && string[i+1] == esc) { + i++; + unicode_buffer[++j] = esc; + } + } /* if (skip==0) */ + j++; + } /* for (j=i=0;i<len;i++) */ + + if (j > 0) { + args.unicode_array_len=j; /* Much easier to set the length than + * work it out later :-) */ + args.unicode_array=&unicode_buffer[0]; /* Get address of the + * unicode buffer (even + * though it is + * currently static) */ + } else + /* Don't print anything, if there is no unicode to print! */ + return; + } /* if (string!=NULL) */ + }/* if (plsc->dev_unicode) */ - if (plsc->dev_unicode) { - args.string=NULL; /* We are using unicode */ - } - else { - args.string = string; - } + if (plsc->dev_unicode) { + args.string=NULL; /* We are using unicode */ + } + else { + args.string = string; + } - plP_esc(PLESC_HAS_TEXT, &args); + plP_esc(PLESC_HAS_TEXT, &args); #ifndef DEBUG_TEXT - } else { + } else { #endif - plstr(base, xform, refx, refy, string); - } + plstr(base, xform, refx, refy, string); + } } static void -- Thomas J. Duck <to...@fi...> Department of Physics and Atmospheric Science, Dalhousie University, Halifax, Nova Scotia, Canada, B3H 3J5. Tel: (902)494-1456 | Fax: (902)494-5191 | Lab: (902)494-3813 Web: http://aolab.phys.dal.ca/~tomduck/ Public key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x17D965DB |
From: Alan W. I. <ir...@be...> - 2005-05-12 18:39:33
|
On 2005-05-12 14:22-0300 Thomas J. Duck wrote: > Hi, > > I understand what Per is on about, and it's important. > > I have been struggling with x24c as well. The problem is that our > unicode implementation currently requires that you have libunicode > installed. If you don't have libunicode (like on my system presently), > then a vital section of code in plcore.c that translates utf8 to ucs4 > does not get executed. ACK!! > > Per has provided us with a nice bit of code that allows us to avoid > libunicode altogether. I have made a few adjustments to it, and have > removed the unnecessary section invoking libunicode from plcore.c. Look > for the block beginning with the words "Per Persson". Note that I > changed the indentation for all of plP_text because I just couldn't deal > with it anymore. ;^) > > I have tested the results for many examples (including x24c) on > the png and gcw drivers, and they appear to be good. I would like to hear > if others accept this patch. If so, then maybe we can apply it for > tomorrow's release. It fixes a *nasty* bug. Please advise. I understand why you wanted to change whitespace for your potential cvs commit, but for the list to understand the patch it would have been better to use the ignore whitespace options for diff. Anyhow, I haven't waded through the patch because I cannot find where the real change were made. However, I infer from your comments that you have replaced a call to a libunicode routine by a section of code embedded in one of our routines. If that is a correct description of what you (and Per) have done, I suggest you define a private function instead to mimic what the libunicode routine does. That keeps everything nicely organized and also makes it straightforward to deal with the next issue I want to discuss. Currently, we are just barely scratching the surface of UTF8 to UCS4 conversion in our tests so as the word spreads and more users start using the new language capabilities of PLplot they may run into problems with our private routine that are not present for libunicode since that code has presumably had much more extensive testing of UTF8 to UCS4 transformations. So I suggest we handle this in the following way: during configuration look for libunicode as now. If it is found use it as now. If not, warn at configuration time that we are falling back to another solution (our private routine for converting UTF8 to UCS4). If everybody agrees this is the obvious way to go, then perhaps it would be okay to make this last minute change before the release, but on general principles of trying to avoid making such last-minute changes, I would lean toward making this change right after the present release so it can be tested by a variety of users on a wide variety of platforms for several weeks before it goes into the next release. It is certainly tempting to try to get the UTF8 conversion to work on more than just the Linux platform, but I am always concerned that a last-minute change might introduce some show-stopper error that we haven't anticipated. That happened to me once when I was RM, I positively hated the scramble that was required to fix it, and I tried to make sure it didn't happen again by being resistant to last-minute changes. But, Tom, this is a matter of personal taste and experience so I am trying to advise you, but ultimately this is your call as the current RM about the timing of the change once we arrive at consensus about what that change should be. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Thomas J. D. <to...@fi...> - 2005-05-12 19:14:29
Attachments:
plcore.c.patch
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Alan, I should probably try to stop breaking things with these last-minute changes anyway. So yes, let's wait until after the 5.3.3 release. In principle, the conversion from utf8 to ucs4 should be pretty simple, no? Maybe Per can comment? Does the PLplot core have any other dependencies beyond libc and libltdl? It makes sense to me to try to keep the core dependencies to a minimum. I don't think it is a good idea to mix both libunicode and our own hacked solutions in the core, because exactly the kinds of problems that Per and I have had will continue to crop up. I think there are two options: 1) Providing our own unicode solutions with no dependencies. 2) Disabling text handling altogether if libunicode is not available. Your thoughts? I have attached the patch without the white-space issue. Cheers, Tom - -- - --- plcore.c 2005-05-12 15:54:44.000000000 -0300 +++ plcore.c.new 2005-05-12 14:05:21.000000000 -0300 @@ -673,11 +673,56 @@ } } + /* This section does utf8 to ucs4 conversion without + * using libunicode. Contributed by Per Persson. + */ if (skip==0) { - -#ifdef HAVE_LIBUNICODE - - unicode_char_t unichar; - - char* ptr = - - unicode_get_utf8 (string + i, &unichar); + PLUNICODE unichar; + char tmp; + char *ptr = (char *)string + i; + int isFirst = 1; + int cnt; + + do { + /* Get next character in string */ + tmp = *ptr++; + if (isFirst) { /* First char in UTF8 sequence */ + isFirst = 0; + /* Determine length of sequence */ + if ((unsigned char)(tmp&0x80)==0x00) { /* single char */ + unichar = (PLUNICODE)tmp & 0x7F; + cnt = 0; + } else if((unsigned char)(tmp&0xE0)==0xC0) { /* 2 chars */ + unichar = (PLUNICODE)(tmp & 0x1F); + cnt = 1; + } else if((unsigned char)(tmp&0xF0)==0xE0) { /* 3 chars */ + unichar = (PLUNICODE)(tmp & 0x0F); + cnt = 2; + } else if((unsigned char)(tmp&0xF8)==0xF0) { /* 4 chars */ + unichar = (PLUNICODE)(tmp & 0x07); + cnt = 3; + } else if((unsigned char)(tmp&0xFC)==0xF8) { /* 5 chars */ + unichar = (PLUNICODE)(tmp & 0x03); + cnt = 4; + } else if((unsigned char)(tmp&0xFE)==0xFC) { /* 6 chars */ + unichar = (PLUNICODE)(tmp & 0x01); + cnt = 5; + } else { /* Malformed */ + ptr = NULL; + cnt = 0; + } + } + else { /* Subsequent char in UTF8 sequence */ + if ((unsigned char)(tmp & 0xC0) == 0x80) { + unichar = (unichar << 6) | ((PLUNICODE)(tmp & 0x3F)); + cnt--; + } + else { /* Malformed */ + ptr = NULL; + cnt = 0; + } + } + } while (cnt > 0); if (ptr == NULL) { char buf[80]; strncpy (buf, string, 30); @@ -686,10 +731,9 @@ plabort (buf); } unicode_buffer [j] = (PLUNICODE) unichar; - - i += ptr - (string + i) - 1; - -#else - - unicode_buffer[j]=string[i]; - -#endif + i = ptr - string - 1; + + /* Search for escesc (an unescaped escape) in the input * string and adjust unicode_buffer accordingly). */ @@ -697,9 +741,10 @@ i++; unicode_buffer[++j] = esc; } - - } + } /* if (skip==0) */ j++; - - } + } /* for (j=i=0;i<len;i++) */ + if (j > 0) { args.unicode_array_len=j; /* Much easier to set the length than * work it out later :-) */ @@ -710,8 +755,8 @@ } else /* Don't print anything, if there is no unicode to print! */ return; - - } - - } + } /* if (string!=NULL) */ + }/* if (plsc->dev_unicode) */ if (plsc->dev_unicode) { args.string=NULL; /* We are using unicode */ - -- Thomas J. Duck <to...@fi...> Department of Physics and Atmospheric Science, Dalhousie University, Halifax, Nova Scotia, Canada, B3H 3J5. Tel: (902)494-1456 | Fax: (902)494-5191 | Lab: (902)494-3813 Web: http://aolab.phys.dal.ca/~tomduck/ Public key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x17D965DB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCg6i8ndxDHhfZZdsRAs1lAKDSRN5FTEAlmkEtY/2eXlP/53GfjACgoi2y i00cpjQNWO8ckigEGGWoy5I= =7ymT -----END PGP SIGNATURE----- |
From: Alan W. I. <ir...@be...> - 2005-05-12 20:56:42
|
On 2005-05-12 16:04-0300 Thomas J. Duck wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Alan, > > I should probably try to stop breaking things with these last-minute > changes anyway. So yes, let's wait until after the 5.3.3 release. Good. > (out of original order for clarity) > I have attached the patch without the white-space issue. Thanks for that. So all it essentially does is replace the call to unicode_get_utf8 (string + i, &unichar); by an embedded block of code. As I have said regardless of the decision about how we use this code, I would prefer a separate private function approach rather than this embedded block of code simply to keep things better organized. I call this proposed private function private_unicode_get_utf8 in the discussion below. > > In principle, the conversion from utf8 to ucs4 should be pretty > simple, no? Maybe Per can comment? I second that question to Per since I cannot comment on this issue, but the full solution for the windows platform is also going to require utf16 (and utf32?) transformations to UCS4 so we may be stuck with an external library at least in the windows case (or libunicode may expand to cover this case). > > Does the PLplot core have any other dependencies beyond libc and > libltdl? It makes sense to me to try to keep the core dependencies to a > minimum. To be specific let's talk about the libplplot library dependencies instead. You can investigate those dependences by looking at $prefix/lib/libplplotd.la. Here is the current list (wrapped for clarity) on my system with a largely default ./configure: # Libraries that this one depends upon. dependency_libs=' /usr/lib/libfreetype.la -lz /usr/local/plplot/lib/libcsirocsa.la /usr/local/plplot/lib/libcsironn.la /usr/lib/libqhull.la -L/usr/lib /usr/lib/libunicode.la -ldl -lm' The ones with the /usr/local/plplot prefix on my system are the ones we build ourselves. > > I don't think it is a good idea to mix both libunicode and our own > hacked solutions in the core, because exactly the kinds of problems that > Per and I have had will continue to crop up. Just out of curiosity, why are you having trouble on your Debian system? apt-get install libunicode-dev should solve it. > I think there are two > options: > > 1) Providing our own unicode solutions with no dependencies. > > 2) Disabling text handling altogether if libunicode is not available. > > Your thoughts? > 3) There is also a 3rd alternative which I favour: Call unicode_get_utf8 when HAVE_LIBUNICODE is defined and call private_unicode_get_utf8 when it is not defined. The important point though, is whatever we decide is probably going to be a temporary solution. My sense is that the free software community (whether Linux, OS X, or Windows based) is becoming quite keen on unicode so there is a tremendous pace of change in this area. Eventually, though this pace of development will settle down and there will be a good free solution that will work on all platforms to transform the platform encodings (whether UTF8, UTF16, or UTF32) to the UCS4 that we use internally. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Thomas J. D. <to...@fi...> - 2005-05-13 16:20:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Alan, > As I have said regardless of the decision about how we use this code, I > would prefer a separate private function approach rather than this embedded > block of code simply to keep things better organized. I call this > proposed private function private_unicode_get_utf8 in the discussion below. OK, no problem. > > I don't think it is a good idea to mix both libunicode and our own > > hacked solutions in the core, because exactly the kinds of problems that > > Per and I have had will continue to crop up. > > Just out of curiosity, why are you having trouble on your Debian system? > > apt-get install libunicode-dev > > should solve it. Yes, but that misses the point. The fact is that I did not have libunicode installed, and it was not required to build PLplot. When I tried x24c and it crashed, there was no indication of what I should do: only these really weird FCI error messages cropped up. We might have users encounter this same scenario. I don't think that giving a warning during configure is sufficient. If it installs, the core should "just work". > > I think there are two > > options: > > > > 1) Providing our own unicode solutions with no dependencies. > > > > 2) Disabling text handling altogether if libunicode is not available. > > > > Your thoughts? > > > > 3) There is also a 3rd alternative which I favour: > > Call unicode_get_utf8 when HAVE_LIBUNICODE is defined and call > private_unicode_get_utf8 when it is not defined. I think that I disagree with this, Alan. Maintainance of the code will become an issue, as two different streams will need to be supported and debugged. I would rather focus on one or the other. Arjen has also pointed out that extra dependencies for the core are a potential problem for some systems. So, I am leaning toward just providing our own solution if it proves simple enough to do. Following this same line of thought, we should probably look into what happens with text calls when Freetype is not available. Cheers, Tom - -- Thomas J. Duck <to...@fi...> Department of Physics and Atmospheric Science, Dalhousie University, Halifax, Nova Scotia, Canada, B3H 3J5. Tel: (902)494-1456 | Fax: (902)494-5191 | Lab: (902)494-3813 Web: http://aolab.phys.dal.ca/~tomduck/ Public key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x17D965DB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFChNF1ndxDHhfZZdsRAsxJAJ9Gs8RTfq+PSMQx5ZaXoZtdNlxt7wCfc+KD qbzhevnDR06XAx8O9RzhAR4= =n9VJ -----END PGP SIGNATURE----- |
From: Alan W. I. <ir...@be...> - 2005-05-13 19:38:16
|
On 2005-05-13 13:10-0300 Thomas J. Duck wrote: >> apt-get install libunicode-dev >> >> should solve it. > > Yes, but that misses the point. The fact is that I did not have > libunicode installed, and it was not required to build PLplot. When > I tried x24c and it crashed, there was no indication of what I should do: > only these really weird FCI error messages cropped up. > > We might have users encounter this same scenario. I don't > think that giving a warning during configure is sufficient. If it > installs, the core should "just work". Absolutely agreed, but this issue should automatically be addressed by the existence of private_unicode_get_utf8 (see below). > >>> I think there are two >>> options: >>> >>> 1) Providing our own unicode solutions with no dependencies. >>> >>> 2) Disabling text handling altogether if libunicode is not available. >>> >>> Your thoughts? >>> >> >> 3) There is also a 3rd alternative which I favour: >> >> Call unicode_get_utf8 when HAVE_LIBUNICODE is defined and call >> private_unicode_get_utf8 when it is not defined. > > I think that I disagree with this, Alan. Maintainance of the code > will become an issue, as two different streams will need to be supported > and debugged. I would rather focus on one or the other. Let's take private_unicode_get_utf8 as a given (although I am not particularly good at choosing names so somebody may want to come up with a better one) since libunicode is not available everywhere at the moment. Then what we are really discussing here is whether or not to add the call to unicode_get_utf8 for the HAVE_LIBUNICODE case. I don't view that extra line of code as much of a maintenance issue. The current autotools configuration files work fine for defining HAVE_LIBUNICODE and the required library dependency, and the only hole in it was when there was not a fallback (and I believe that issue gets automatically addressed by calling private_unicode_get_utf8 when HAVE_LIBUNICODE is not defined). That said, I do understand the appeal of removing a libplplot dependency so if you want to comment out that line of code and comment out the link to libunicode in Makefile.am on those grounds, that is fine with me. However, I am not the guy you really have to convince. Rafael was the one who introduced the call to unicode_get_utf8 in the first place so I am curious about his take on this issue. (My apologies in advance, Rafael, if you have already posted on this issue and I missed it.) Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Thomas J. D. <to...@fi...> - 2005-05-13 20:15:54
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Alan, > > I think that I disagree with this, Alan. Maintainance of the code > > will become an issue, as two different streams will need to be supported > > and debugged. I would rather focus on one or the other. > > Let's take private_unicode_get_utf8 as a given (although I am not > particularly good at choosing names so somebody may want to come up with a > better one) since libunicode is not available everywhere at the moment. Then > what we are really discussing here is whether or not to add the call to > unicode_get_utf8 for the HAVE_LIBUNICODE case. I don't view that extra line > of code as much of a maintenance issue. You are probably right, and I am making a mountain out of a molehill. What I am worried about is weird bugs popping up for some of us, and not for others. This was exactly the case here, and had Per not posted his solution, I never would have figured it out. My own Debian results didn't agree with either yours or Rafael's, which had me pretty perplexed. If there is some bug in our "alternate" unicode implementation, it may be very hard for the few people inflicted with it to track it down. When everybody is running the same code, the problems are easier to identify and eliminate. It would be nice for others with interest in this topic to weigh in with their advice before we move ahead. I think that we reached concensus on our "colour styles" issue before, and so I will try to implement that soon. Cheers, Tom - -- Thomas J. Duck <to...@fi...> Department of Physics and Atmospheric Science, Dalhousie University, Halifax, Nova Scotia, Canada, B3H 3J5. Tel: (902)494-1456 | Fax: (902)494-5191 | Lab: (902)494-3813 Web: http://aolab.phys.dal.ca/~tomduck/ Public key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x17D965DB UFA Faculty position: see http://www.physics.dal.ca/files/UFA_2005-06.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFChQidndxDHhfZZdsRAlSZAKDF9jv2TdBd/fRtLqVAa8dIdxRPJwCeK7rQ 2TXeSaup02uwVbYbxk2t+9g= =VQ/S -----END PGP SIGNATURE----- |
From: Alan W. I. <ir...@be...> - 2005-07-13 18:29:19
|
On 2005-05-13 17:05-0300 Thomas J. Duck wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Alan, > >>> I think that I disagree with this, Alan. Maintainance of the code >>> will become an issue, as two different streams will need to be supported >>> and debugged. I would rather focus on one or the other. >> >> Let's take private_unicode_get_utf8 as a given (although I am not >> particularly good at choosing names so somebody may want to come up with a >> better one) since libunicode is not available everywhere at the moment. Then >> what we are really discussing here is whether or not to add the call to >> unicode_get_utf8 for the HAVE_LIBUNICODE case. I don't view that extra line >> of code as much of a maintenance issue. > > You are probably right, and I am making a mountain out of a molehill. > What I am worried about is weird bugs popping up for some of us, and not > for others. This was exactly the case here, and had Per not posted his > solution, I never would have figured it out. My own Debian results didn't > agree with either yours or Rafael's, which had me pretty perplexed. If > there is some bug in our "alternate" unicode implementation, it may be > very hard for the few people inflicted with it to track it down. When > everybody is running the same code, the problems are easier to identify > and eliminate. > Walt Brainerd has just run into the "no libunicode" issue on Cygwin for -dev png. The result with the present code was a silent failure (no error messages) of all text, i.e., all text in the examples was rendered as blank. IIRC both Per (on Mac OS X) and Tom (on Debian) also ran into problems when libunicode was not present so this issue needs to be addressed. Tom, nobody commented on what you said above (in May) so I think we have long since reached consensus to implement Per's utf8 ==> UCS4 conversion routine as a simple separate function that we maintain. For now, lets turn off with-unicode by default in cf/unicode.ac (ie replace PL_ARG_WITH(libunicode, [Use libunicode for decoding UTF-8 strings], [yes]) ==> PL_ARG_WITH(libunicode, [Use libunicode for decoding UTF-8 strings instead of internal routine], [no]) This means HAVE_LIBUNICODE will normally not be defined and plcore.c should be changed to call the private conversion routine for the #else clause of #ifdef HAVE_LIBUNICODE. That by default removes the libunicode dependency which is a good thing, but also allows us to easily bring it back for testing purposes (on a system with libunicode installed) if we ever run into any problems with our private conversion routine. Tom, you were close to committing the change just before the release of 5.5.3, but you were convinced (by the "no last-minute change" argument to delay until after the release. However, now it is long past time to get this essential fix committed so please just go ahead. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Thomas J. D. <to...@fi...> - 2005-07-14 15:45:47
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OK, Alan. Will do. --Tom - -- On Wed, 13 Jul 2005, Alan W. Irwin wrote: > On 2005-05-13 17:05-0300 Thomas J. Duck wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi Alan, > > > >>> I think that I disagree with this, Alan. Maintainance of the code > >>> will become an issue, as two different streams will need to be supported > >>> and debugged. I would rather focus on one or the other. > >> > >> Let's take private_unicode_get_utf8 as a given (although I am not > >> particularly good at choosing names so somebody may want to come up with a > >> better one) since libunicode is not available everywhere at the moment. Then > >> what we are really discussing here is whether or not to add the call to > >> unicode_get_utf8 for the HAVE_LIBUNICODE case. I don't view that extra line > >> of code as much of a maintenance issue. > > > > You are probably right, and I am making a mountain out of a molehill. > > What I am worried about is weird bugs popping up for some of us, and not > > for others. This was exactly the case here, and had Per not posted his > > solution, I never would have figured it out. My own Debian results didn't > > agree with either yours or Rafael's, which had me pretty perplexed. If > > there is some bug in our "alternate" unicode implementation, it may be > > very hard for the few people inflicted with it to track it down. When > > everybody is running the same code, the problems are easier to identify > > and eliminate. > > > > Walt Brainerd has just run into the "no libunicode" issue on Cygwin for -dev > png. The result with the present code was a silent failure (no error > messages) of all text, i.e., all text in the examples was rendered as blank. > IIRC both Per (on Mac OS X) and Tom (on Debian) also ran into problems when > libunicode was not present so this issue needs to be addressed. > > Tom, nobody commented on what you said above (in May) so I think we have > long since reached consensus to implement Per's utf8 ==> UCS4 conversion > routine as a simple separate function that we maintain. For now, lets turn > off with-unicode by default in cf/unicode.ac (ie replace > PL_ARG_WITH(libunicode, [Use libunicode for decoding UTF-8 strings], [yes]) > ==> > PL_ARG_WITH(libunicode, [Use libunicode for decoding UTF-8 strings instead > of internal routine], [no]) > > This means HAVE_LIBUNICODE will normally not be defined and plcore.c should > be changed to call the private conversion routine for the #else clause of > #ifdef HAVE_LIBUNICODE. > > That by default removes the libunicode dependency which is a good thing, but > also allows us to easily bring it back for testing purposes (on a system > with libunicode installed) if we ever run into any problems with our private > conversion routine. > > Tom, you were close to committing the change just before the release of > 5.5.3, but you were convinced (by the "no last-minute change" argument to > delay until after the release. However, now it is long past time to get > this essential fix committed so please just go ahead. > > Alan > __________________________ > Alan W. Irwin > email: ir...@be... > phone: 250-727-2902 > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the > Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > - -- Thomas J. Duck <to...@fi...> Department of Physics and Atmospheric Science, Dalhousie University, Halifax, Nova Scotia, Canada, B3H 3J5. Tel: (902)494-1456 | Fax: (902)494-5191 | Lab: (902)494-3813 Web: http://aolab.phys.dal.ca/~tomduck/ Public key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x17D965DB UFA faculty position: see http://www.physics.dal.ca/files/UFA_2005-06.html Departmental chair search: http://www.physics.dal.ca/physics_4310.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1oZfndxDHhfZZdsRAlH3AKDJwTWotbGybhy6p3dIBTU6xK0ZkQCdFvqc KlUDKoWu+ew2InM5JbFcuMc= =64x9 -----END PGP SIGNATURE----- |
From: Per P. <per...@ma...> - 2005-05-14 08:39:36
|
Hi all, sorry to reply so late, been busy. I don't have any strong opinions on the plcore design, but I'd like to comment on the utf8->ucs4 conversion. On May 12, 2005, at 21:04, Thomas J. Duck wrote: > In principle, the conversion from utf8 to ucs4 should be pretty > simple, no? Maybe Per can comment? Yes, the mapping is very simple: A first byte with a length marker, indicating the number of subsequent bytes if any, and the first run of bits. Subsequent bytes have the form 10xxxxxx where the xxxxxx represent the bits to shuffle into the 32 bit ucs4 rep. This is not a piece of code that is hard to maintain, nor will the encoding change in the future. There is a very good article over at http://www-128.ibm.com/ developerworks/library/l-linuni.html /Per |
From: Alan W. I. <ir...@be...> - 2005-05-14 21:07:11
|
On 2005-05-14 10:39+0200 Per Persson wrote: > There is a very good article over at http://www-128.ibm.com/ > developerworks/library/l-linuni.html Thanks for that reference which I agree seemed to be a good article about Linux and Unicode. However, one limitation is it is somewhat dated- 2001-August-10. Does anybody know of an up-to-date equivalent? Another limitation is it is restricted almost entirely to Linux. For example, it says "wchar_t is intended to be used only for 32-bit ISO 10646 values". Does anybody know whether that type would be a better cross-platform solution than our current "typedef uint32_t PLUNICODE;"? Despite the limitations, that article has given me some food for thought about the best way to mark the FCI. Currently, and FCI is distinguished from the 32-bit UCS4 unsigned integer by marking the highest order hex digit by 0x1. I picked that marking digit because the corresponding 32-bit integer value of 16^7 = 2^28 ~ 2.6 x10^8 seemed to be far beyond any UCS-4 code ever planned. (I think the current maximum UCS4 value is roughly 2 million). But it turns out from the article that theoretically UCS-4 could reach 128 groups which corresponds to a maximum value of 2^31-1. Another way of saying this is the current FCI marking potentially interferes with UCS-4 group 16 (if that large a group is ever implemented). To avoid this potential future interference, I think it would be better to change the FCI marking to 0x8 which corresponds to UCS-4 group 128 which should never exist according to the article (the maximum potential group number is 2^7-1 = 127). Note I have checked through our CVS files for "0x1" and there are a number of locations that would have to be changed (mostly our internal font codes), but it doesn't look too bad because normally the #defined constant PL_FCI_MARK is used within our code as "#define PL_FCI_MARK 0x10000000". Here is a C language question: in case we want to change PL_FCI_MARK again, how can I specify our internal font codes to take this into account? For example, right now we have const FCI_to_FontName_Table Type1Lookup[N_Type1Lookup] = { {0x10000000, "Helvetica"}, {0x10000001, "Times-Roman"}, ... in include/plfci-type1.h. Can I use {PL_FCI_MARK+0x0, "Helvetica"}, {PL_FCI_MARK+0x1, "Times-Roman"}, etc.? Or would it be better to use the following idea? #define PL_FCI_MARK_HEX 0x1 (or whatever the case may be?) #define PL_FCI_MARK PL_FCI_MARK_HEX0000000 and {PL_FCI_MARK_HEX0000000, "Helvetica"}, {PL_FCI_MARK_HEX0000001, "Times-Roman"}, etc.? Those users who have been specifying FCI's using 0x1nnnnnnn would have to move to 0x8nnnnnnn (or better yet PL_FCI_MARK + whatever), but since this FCI technology has just recently been introduced and the documentation of the three possible methods for changing the FCI was wrong in any case (see recent commit), I think this is going to require changes for only a tiny minority (if any) of our users. However, I would rather deal with it now rather than 10 years from now when lots of our users will be used to using this mark. Let me know what you think of (a) changing the mark, and (b) generalizing our code and documentation so future changes (if required) will be easier. If I don't hear any objections within the next few days, I will go ahead. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Per P. <per...@ma...> - 2005-05-15 19:19:30
|
On May 14, 2005, at 23:05, Alan W. Irwin wrote: > Here is a C language question: in case we want to change > PL_FCI_MARK again, > how can I specify our internal font codes to take this into account? > For example, right now we have > > const FCI_to_FontName_Table Type1Lookup[N_Type1Lookup] = { > {0x10000000, "Helvetica"}, > {0x10000001, "Times-Roman"}, > ... > > in include/plfci-type1.h. Can I use > > {PL_FCI_MARK+0x0, "Helvetica"}, > {PL_FCI_MARK+0x1, "Times-Roman"}, > > etc.? Yes, or even better IMHO using the bitwise OR operation {PL_FCI_MARK | 0x0, "Helvetica"} > Or would it be better to use the following idea? > > #define PL_FCI_MARK_HEX 0x1 (or whatever the case may be?) > #define PL_FCI_MARK PL_FCI_MARK_HEX0000000 > > and > > {PL_FCI_MARK_HEX0000000, "Helvetica"}, > {PL_FCI_MARK_HEX0000001, "Times-Roman"}, > > etc.? No, no, no... please, my eyes! I'm going blind.... ;-) Seriously, no. That is completely unreadable precompiler abuse. A common pattern when creating (unsigned) 32 bit binary numbers from a set of options is someting like #define PL_FCI_MARK 0x80000000 #define FAMILY(a) ((a) << 0) #define TRAIT(a) ((a) << 8) #define MORE_OPTS(a) ((a) << 16) typedef enum { SERIF = 0, SANS_SERIF, MONO } font_family; typedef enum { ROMAN = 0, ITALIC } font_trait; uint32 my_fci = PL_FCI_MARK | FAMILY(SERIF) | TRAIT(ITALIC) | MORE_OPTS(BOLD); You'll notice that I didn't look up the actual definition of an FCI, but I hope you get the essence of what I'm trying to convey. /Per |
From: Alan W. I. <ir...@be...> - 2005-05-20 22:50:24
|
On 2005-05-15 21:18+0200 Per Persson wrote: > > On May 14, 2005, at 23:05, Alan W. Irwin wrote: > >> Here is a C language question: in case we want to change PL_FCI_MARK >> again, >> how can I specify our internal font codes to take this into account? >> For example, right now we have >> >> const FCI_to_FontName_Table Type1Lookup[N_Type1Lookup] = { >> {0x10000000, "Helvetica"}, >> {0x10000001, "Times-Roman"}, >> ... >> >...[use] the bitwise OR operation > {PL_FCI_MARK | 0x0, "Helvetica"} > OK. I have made those changes just to make the code a little cleaner, but I haven't yet changed PL_FCI_MARK, and depending on the guidance I get from Rafael and Maurice, I may not do so since technically this is an API change. My understanding is any backwards incompatible change in meaning of a function argument is an API change (since old code that uses PL_FCI_MARK or which marks FCI's with 0x10000000 wont work), but I use "technically" here because I really don't think many (if any) users will be affected by the change in interpretation of what distinguishes an FCI from UCS-4. FCI's are a recently introduced (at PLplot-5.5.0) feature, and the user's ability to specify absolute FCI's (which currently includes a mark of 0x10000000 which I want to change to 0x80000000) has only been documented correctly for our latest release. (Search for 0x1 in http://plplot.sourceforge.net/docbook-manual/plplot-html-5.5.3/characters.html.) Could I have some practical guidance from especially Maurice and Rafael (the combined API concience for PLplot developers) please on whether it is okay to go ahead and change PL_FCI_MARK from 0x10000000 to 0x80000000? Rafael, even if you say "go ahead" because you feel this is too inconsequential a backwards-incompatible API change to worry about, I will still wait for Maurice's "OK" as well. I understand Maurice may be out of e-mail contact for a while, but, Rafael, don't let that stop you from commenting sooner on this API change. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <mj...@ga...> - 2005-05-21 02:56:20
|
Alan W. Irwin writes: > Could I have some practical guidance from especially Maurice and Rafael (the > combined API concience for PLplot developers) please on whether it is okay > to go ahead and change PL_FCI_MARK from 0x10000000 to 0x80000000? Rafael, > even if you say "go ahead" because you feel this is too inconsequential a > backwards-incompatible API change to worry about, I will still wait for > Maurice's "OK" as well. I understand Maurice may be out of e-mail contact > for a while, but, Rafael, don't let that stop you from commenting sooner on > this API change. I don't feel strongly on the matter. Since it's a "relatively" new feature, I think it's a given that there be some (suitably chosen) period of instability before the interface completely crystallizes. That's the price for being an early adopter. It also depends on how you pitch it to begin with. If a new capability is sufficiently complex that you feel like you need feedback in order to understand all the angles, you might label it as "experimental" and retain more latitude for changing things around later. As long as we have some reasonable bounds on the duration of "experimental" works in progress.. we obviously don't want the entire code base marked that way. :) -- Maurice LeBrun mj...@ga... |
From: Rafael L. <rla...@us...> - 2005-05-22 09:34:58
|
* mj...@ga... <mj...@ga...> [2005-05-20 20:50]: > Alan W. Irwin writes: > > Could I have some practical guidance from especially Maurice and Rafael (the > > combined API concience for PLplot developers) please on whether it is okay > > to go ahead and change PL_FCI_MARK from 0x10000000 to 0x80000000? Rafael, > > even if you say "go ahead" because you feel this is too inconsequential a > > backwards-incompatible API change to worry about, I will still wait for > > Maurice's "OK" as well. I understand Maurice may be out of e-mail contact > > for a while, but, Rafael, don't let that stop you from commenting sooner on > > this API change. > > I don't feel strongly on the matter. Since it's a "relatively" new feature, I > think it's a given that there be some (suitably chosen) period of instability > before the interface completely crystallizes. That's the price for being an > early adopter. It also depends on how you pitch it to begin with. If a new > capability is sufficiently complex that you feel like you need feedback in > order to understand all the angles, you might label it as "experimental" and > retain more latitude for changing things around later. As long as we have > some reasonable bounds on the duration of "experimental" works in progress.. > we obviously don't want the entire code base marked that way. :) I agree with Maurice's considerations. I think we are allowed to introduced backward incompatible changes for features introduced in the 5.5.x series. -- Rafael |
From: Alan W. I. <ir...@be...> - 2005-05-22 15:56:37
|
On 2005-05-22 11:34+0200 Rafael Laboissiere wrote: > * mj...@ga... <mj...@ga...> [2005-05-20 20:50]: > >> Alan W. Irwin writes: >> > Could I have some practical guidance from especially Maurice and Rafael (the >> > combined API concience for PLplot developers) please on whether it is okay >> > to go ahead and change PL_FCI_MARK from 0x10000000 to 0x80000000? Rafael, >> > even if you say "go ahead" because you feel this is too inconsequential a >> > backwards-incompatible API change to worry about, I will still wait for >> > Maurice's "OK" as well. I understand Maurice may be out of e-mail contact >> > for a while, but, Rafael, don't let that stop you from commenting sooner on >> > this API change. >> >> I don't feel strongly on the matter. Since it's a "relatively" new feature, I >> think it's a given that there be some (suitably chosen) period of instability >> before the interface completely crystallizes. That's the price for being an >> early adopter. It also depends on how you pitch it to begin with. If a new >> capability is sufficiently complex that you feel like you need feedback in >> order to understand all the angles, you might label it as "experimental" and >> retain more latitude for changing things around later. As long as we have >> some reasonable bounds on the duration of "experimental" works in progress.. >> we obviously don't want the entire code base marked that way. :) > > I agree with Maurice's considerations. I think we are allowed to introduced > backward incompatible changes for features introduced in the 5.5.x series. I think that is a good policy. Maurice and Rafael, do you think we should state this policy in general in the 5.5.x release announcements (README.release)? If so, please go ahead and put in the wording that you like. I will go ahead and make the proposed PL_FCI_MARK change soon as well as warning about this specific API change in README.release. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2005-05-22 17:28:07
|
On 2005-05-22 08:55-0700 Alan W. Irwin wrote: > > I will go ahead and make the proposed PL_FCI_MARK change soon as well as > warning about this specific API change in README.release. > Done. Also, I performed some superficial Linux build and installed examples tests. Please test this series of commits yourselves (especially Hazen and Arjen since I cannot test changes to drivers/aqt.c and sys/win32/msdev/src/plplot.h). Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Per P. <per...@ma...> - 2005-05-22 18:59:01
|
With the recent developments in unicode aware drivers, I've been thinking a bit about the naming of the environment variables used to specify fonts. Currently the are named PLPLOT_FREETYPE_SYMBOL_FONT etc., but it seems to me that this is a naming scheme that in the long run might become confusing. As more and more drivers are devloped, not all of them will rely on freetype for unicode handling. Using AquaTerm as an example, the PLPLOT_FREETYPE_SYMBOL_FONT value is pulled in (and stripped of any path and/or extension) and the driver then uses standard (on Mac OS X) system calls to handle font changes. My question (suggestion really) is if it is possible to instead use generic names e.g. PLPLOT_SYMBOL_FONT and let the individual drivers decide how to handle the information passed. Regards, Per |
From: Alan W. I. <ir...@be...> - 2005-05-22 20:47:50
|
On 2005-05-22 20:58+0200 Per Persson wrote: > With the recent developments in unicode aware drivers, I've been thinking a > bit about the naming of the environment variables used to specify fonts. > Currently the are named PLPLOT_FREETYPE_SYMBOL_FONT etc., but it seems to me > that this is a naming scheme that in the long run might become confusing. > > As more and more drivers are devloped, not all of them will rely on freetype > for unicode handling. Using AquaTerm as an example, the > PLPLOT_FREETYPE_SYMBOL_FONT value is pulled in (and stripped of any path > and/or extension) and the driver then uses standard (on Mac OS X) system > calls to handle font changes. > > My question (suggestion really) is if it is possible to instead use generic > names e.g. PLPLOT_SYMBOL_FONT and let the individual drivers decide how to > handle the information passed. I have done a quick check through the source and there doesn't seem to be any technical (e.g., name clash) problems with such a change. Also, I can understand why Per and authors of possible future device drivers that do not use plfreetype.c would like more generic names for the environment variables. But there may be something I am missing that Andrew Roach (as the original author of all the plfreetype stuff) will know about. What do you think of Per's generic name suggestion, Andrew? Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <aro...@ya...> - 2005-05-23 05:29:35
|
At 01:47 PM 22/05/2005 -0700, you wrote: >On 2005-05-22 20:58+0200 Per Persson wrote: > >>With the recent developments in unicode aware drivers, I've been thinking >>a bit about the naming of the environment variables used to specify >>fonts. Currently the are named PLPLOT_FREETYPE_SYMBOL_FONT etc., but it >>seems to me that this is a naming scheme that in the long run might >>become confusing. >> >>As more and more drivers are devloped, not all of them will rely on >>freetype for unicode handling. Using AquaTerm as an example, the >>PLPLOT_FREETYPE_SYMBOL_FONT value is pulled in (and stripped of any path >>and/or extension) and the driver then uses standard (on Mac OS X) system >>calls to handle font changes. >> >>My question (suggestion really) is if it is possible to instead use >>generic names e.g. PLPLOT_SYMBOL_FONT and let the individual drivers >>decide how to handle the information passed. > >I have done a quick check through the source and there doesn't seem to be >any technical (e.g., name clash) problems with such a change. Also, I can >understand why Per and authors of possible future device drivers that do not >use plfreetype.c would like more generic names for the environment >variables. But there may be something I am missing that Andrew Roach (as the >original author of all the plfreetype stuff) will know about. I think the change from PLPLOT_SYMBOL_FONT to PLPLOT_FREETYPE_SYMBOL_FONT only came in with the expanded FCI changes, though I am not 100% sure off the top of my head. My one area of "concern" for Per's proposal is that if there are multiple drivers that eventually support different font rendering systems, by loading fonts into a generic environmental variable, "PLPLOT_SYMBOL_FONT", it may bread even more confusion and less flexibility. For example, suppose we have a freetype driver that uses a TT font, lets say the GD driver, and another driver that uses another font technology - as a non-implemented example, let us say the CGM driver (which in theory supports fonts, but not true type). The two drivers would have completely different fonts needed to specify the symbol font, and if you wanted to choose the driver at run-time, you would have to ensure you set the correct environmental variable before running, lest it not know which font you wanted; forcing that step takes a lot of flexibility away from the concept of environmental variables as well as having multiple concurrent user-selectable drivers. In my mind the environmental variables are usually set up once on a system, perhaps changed occasionally, but not the sort of thing you do every day, or every invocation of the program; having a single generic environmental variable shared among different co-existing font rendering technologies would potentially mean constantly redefining the variables whenver you wanted to change the driver. By having a PLPLOT_FREETYPE_SYMBOL_FONT and a PLPLOT_CGM_SYMBOL_FONT environmental variable, both could be satisfied. That is not to say that I am averse to a generic one as well - perhaps "PLPLOT_SYMBOL_FONT" could be a top-level environmental variable, and in the *absence* of a PLPLOT_FREETYPE_SYMBOL_FONT or a PLPLOT_CGM_SYMBOL_FONT environmental variable, be used by all drivers as they see fit. -Andrew |
From: Alan W. I. <ir...@be...> - 2005-05-23 18:05:17
|
On 2005-05-23 15:29+1000 Andrew Roach wrote: > My one area of "concern" for Per's proposal is that if there are multiple > drivers that eventually support different font rendering systems, by loading > fonts into a generic environmental variable, "PLPLOT_SYMBOL_FONT", it may > bread even more confusion and less flexibility. For example, suppose we have > a freetype driver that uses a TT font, lets say the GD driver, and another > driver that uses another font technology - as a non-implemented example, let > us say the CGM driver (which in theory supports fonts, but not true type). > The two drivers would have completely different fonts needed to specify the > symbol font, and if you wanted to choose the driver at run-time, you would > have to ensure you set the correct environmental variable before running, > lest it not know which font you wanted; forcing that step takes a lot of > flexibility away from the concept of environmental variables as well as > having multiple concurrent user-selectable drivers. In my mind the > environmental variables are usually set up once on a system, perhaps changed > occasionally, but not the sort of thing you do every day, or every invocation > of the program; having a single generic environmental variable shared among > different co-existing font rendering technologies would potentially mean > constantly redefining the variables whenver you wanted to change the driver. > By having a PLPLOT_FREETYPE_SYMBOL_FONT and a PLPLOT_CGM_SYMBOL_FONT > environmental variable, both could be satisfied. That is not to say that I am > averse to a generic one as well - perhaps "PLPLOT_SYMBOL_FONT" could be a > top-level environmental variable, and in the *absence* of a > PLPLOT_FREETYPE_SYMBOL_FONT or a PLPLOT_CGM_SYMBOL_FONT environmental > variable, be used by all drivers as they see fit. Andrew, I understand your concern. There is no way users would want to be constantly changing generic font environment variables for each separate device driver they were using. But I don't think it is a concern we have to worry about. Aren't the current choices really just truetype or type1? For now, we could use PLPLOT_TT_SYMBOL_FONT, etc., as generic cross-device truetype environment variables for the truetype fonts. I don't think we will ever need PLPLOT_TYPE1_SYMBOL_FONT for type 1 fonts since there is so little choice there. (For ps.c, for example, I just use a fixed set of the 30 type1 fonts, since basically that is all that is available.) However, I would like to keep TT in the generic name just in case some day we would like to have user choice for some other completely different kind of font. The other potential concern is that for TrueType fonts, different systems are being used by different devices to access them. For example, the gd.c device drivers currently use the font directory and font file names, while aqt.c (AFAIK) uses the font names and OS X system software to translate those names into the appropriate font. So that is awkward on OS X since gd.c will want file names and aqt.c will want font names. The workaround for now is that Per and Hazen strip out all the directory and file name stuff to derive the font name required by aqt.c. However, I believe a much better solution is always to use truetype font names within PLplot, and then use system software (such as that used by aquaterm or, for example, fontconfig on Linux and windows systems) to find the installed system font corresponding to the specified font name. In sum, I think the best solution for the environment variable issue is to label our cross-driver generic font environment variables by the type of fonts (TrueType, Type 1) that we are dealing with, although the Type 1 versions are not needed at the moment and may never be needed. Currently, workarounds exist for the font file versus font name issue for TrueType fonts, but in the future it should be possible to change over to a system that always uses font names for TrueType fonts within PLplot. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <aro...@ya...> - 2005-05-24 06:18:20
|
At 11:04 AM 23/05/2005 -0700, you wrote: >Andrew, I understand your concern. There is no way users would want to be >constantly changing generic font environment variables for each separate >device driver they were using. But I don't think it is a concern we have= to >worry about. Aren't the current choices really just truetype or type1? Freetype supports both type1 and truetype, and also a few more than those=20 two, although I can not remember the names of all the font types it=20 supports (it also support windows 'vector' fonts for example). Freetype=20 also supports them 100% transparently - there is no need to tell the engine= =20 if it has a type1 or truetype - just give it an absolute path, and it does= =20 the rest for you. >For >now, we could use PLPLOT_TT_SYMBOL_FONT, etc., as generic cross-device >truetype environment variables for the truetype fonts. I don't see a problem with that for truetype fonts, but it does not leave=20 much room for using other font types with the freetype driver, which might= =20 take a lot of potential power away. Also, I am not 100% sure about it, but= =20 I think that Mac's can natively use both Truetype and type 1 fonts. >The other potential concern is that for TrueType fonts, different systems >are being used by different devices to access them. For example, the gd.c >device drivers currently use the font directory and font file names, while >aqt.c (AFAIK) uses the font names and OS X system software to translate >those names into the appropriate font. So that is awkward on OS X since >gd.c will want file names and aqt.c will want font names. The workaround >for now is that Per and Hazen strip out all the directory and file name >stuff to derive the font name required by aqt.c. However, I believe a much >better solution is always to use truetype font names within PLplot, and= then >use system software (such as that used by aquaterm or, for example, >fontconfig on Linux and windows systems) to find the installed system font >corresponding to the specified font name. Freetype elegantly 'avoids' this issue and uses absolute paths, I think=20 because system dependencies from Windows, to Linux, to Mac are so=85 well=85= =20 system dependent ! How we overcome it for all platforms might not be so=20 simple. One thing that I do think is important though is to retain=20 backwards compatibility. Absolute paths will always work, and should always= =20 be supported. On my system C:\WINDOWS\FONTS\georgiaz.TTF is the same as=20 "Georgia Bold Italic" (not that you could tell from the name :-S), and=20 there are any number of ways of telling one as being an absolute path and=20 one being a font name - that is the easy part; the hard part is working out= =20 from system to system where "Georgia Bold Italic" resides. I do not know of= =20 any automatic way to do it under windows, but I am sure there is one=20 somewhere. Windows, like the Mac OS natively only supports "font names" not= =20 "font paths" - the wingcc driver uses freetype for rendering, not the=20 windows font API, so the situation is somewhat moot. >In sum, I think the best solution for the environment variable issue is to >label our cross-driver generic font environment variables by the type of >fonts (TrueType, Type 1) that we are dealing with, although the Type 1 >versions are not needed at the moment and may never be needed. I really do not know what the best way to handle all of this is. I think it= =20 is important to remember that drivers using freetype, and I presume the aqt= =20 driver, transparently support more font types than *just* truetype.=20 Splitting the generic variable into truetype and type1 would add confusion= =20 to those drivers - which do they use ? I still wonder if it might not be=20 better to have two levels of environmental variables, one for a=20 driver-level (I don't mean 'driver specific' - wingcc and GD, both using=20 freetype, should share), and the other a generic one. I think the generic=20 one should be VERY generic, not having any hint of whether it is truetype,= =20 type1, or whatever. In the absence of a driver-specific variable, the=20 driver makes the most of the generic one and figures out what to do. Most=20 (but not necessarily all) of the time, since most drivers will support=20 truetype, that will probably be a truetype font. So most of the time, most= =20 drivers would access the font through the generic variable only, and it=20 would only ever be very specific and perhaps unusual occasions where the=20 driver-level variable would be used. Ultimately the variables, be they generic or driver-specific, should allow= =20 either a font path OR a font name interchangeably. But, like I said, I am not sure what the best approach all up would be, if= =20 there even is a better or best approach. This is something other people=20 might have opinions on. -Andrew |
From: Alan W. I. <ir...@be...> - 2005-05-24 07:19:42
|
On 2005-05-24 15:21+1000 Andrew Roach wrote: > On my system C:\WINDOWS\FONTS\georgiaz.TTF is the same as "Georgia > Bold Italic" (not that you could tell from the name :-S), and there are any > number of ways of telling one as being an absolute path and one being a font > name - that is the easy part; the hard part is working out from system to > system where "Georgia Bold Italic" resides. I do not know of any automatic > way to do it under windows. This example highlights the exact distinction I was making between font name and font file name. fontconfig solves this problem by translating the "Georgia Bold Italic" font name to whatever installed font file name is appropriate for the windows or Unix system that fontconfig is installed on, e.g., C:\WINDOWS\FONTS\georgiaz.TTF on windows systems. Also, fontconfig is designed to work directly with libfreetype2, and it thus supports a wide variety of different kinds of fonts (beyond just TrueType and Type 1). So it might be the answer we need to substantially simplify our environment variable requirements, and I hope someone investigates it further. >> In sum, I think the best solution for the environment variable issue is to >> label our cross-driver generic font environment variables by the type of >> fonts (TrueType, Type 1) that we are dealing with, although the Type 1 >> versions are not needed at the moment and may never be needed. > > ...I think it > is important to remember that drivers using freetype, and I presume the aqt > driver, transparently support more font types than *just* truetype. Splitting > the generic variable into truetype and type1 would add confusion to those > drivers - which do they use ? Good point. I admit my previous remarks were too focussed on TTF because that is far and away the best font type on Linux in terms of availability of lots of free (in the free-speech sense) alternatives, but you are right we should take a broader view that doesn't preclude a variety of font type possibilities. > But, like I said, I am not sure what the best approach all up would be, if > there even is a better or best approach. This is something other people might > have opinions on. It may turn out that fontconfig is so powerful that the environment variables we use to describe font names (as opposed to the quite different file names) can be quite generic. Unfortunately I have no time to investigate the fontconfig possibility further, but I hope you or someone else will be able to take up this challenge since it may make some/all of this discussion moot. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |