Hi Alan,
On 2010-12-20 20:22, Alan W. Irwin wrote:
> Hi Arjen:
>
> On 2010-12-20 10:00+0100 Arjen Markus wrote:
>
>> I think the [example 24] issue has to do with the character encodings.
>> Tcl internally
>> works with UTF-8 and on Windows the system encoding is cp1252 (at least
>> on my machine). I have been experimenting with different encodings but
>> no success yet. I guess I first have to understand _exactly_ what is
>> going on before I can solve it.
>
> To review how this is supposed to work, the language examples (Tcl in
> this case) should encode each PLplot user string as a UTF-8 string,
> and that string should be passed directly without transformation to
> the PLplot C level as a UTF-8 string by the bindings (Tcl in this
> case). The PLplot C core library then translates the UTF-8 string
> into an unsigned 32-bit (PLUNICODE) array consisting of FCI's
> (representing the ascii font-changing commands embedded in the string)
> and UCS4 indices (representing the UTF-8 unicode encoding in the
> string). Our modern device drivers such as cairo and qt then interpret
> that array further to make the appropriate library call for an FCI to
> change the font or to use the UCS4 index to access a particular glyph
> for TrueType fonts. There is one more layer of indirection for -dev
> psc; it translates the UCS4 indices into indices that are suitable for
> indexing Type 1 fonts with the overwhelming majority of results being
> the index for Type 1 blank because Type 1 fonts have an extremely
> limited number of glyphs they can represent. So if there was some
> screwup in encoding at the Tcl level that generates random UCS4
> indices, the most probable response for -dev psc would be a blank
> glyph which would be rather useless for diagnostic purposes. So I
> suggest it would be much better to use one of the cairo or qt devices
> to diagnose what is going wrong at the Tcl example 24 or bindings
> level since the result of random UCS4 garbage would be more likely to
> end up as non-blank glyphs.
>
I solved it, based on a suggestion from a fellow Tcler: we need to
pass the string to a Tcl_UtfToExternal*() function. The problem on
Windows is that the system encoding is _not_ UTF-8, but cp1252.
The strings in the source are therefore translated from cp1252 to UTF-8,
so that the resulting string represents these characters. Using said
function undoes this translation: the PLplot routines receive the
original sequence of bytes.
I have not implemented it yet in pltclgen.tcl, but that should be
easy enough. (I have instead tested it in the _generated_ source and
that gives results that are identical to the C output.)
Could someone check that this is the case on Linux as well? Here is
the adjusted source for the plptex wrapper (use this instead of the
generated source in tclgen.c):
/*--------------------------------------------------------------------------*\
* plptexCmd
*
* Processes plptex Tcl command.
\*--------------------------------------------------------------------------*/
static int
plptexCmd( ClientData clientData, Tcl_Interp *interp, int argc, const
char *argv[] )
{
PLFLT x;
PLFLT y;
PLFLT dx;
PLFLT dy;
PLFLT just;
const char *text;
int i;
Tcl_DString dstring;
pl_errcode = 0; errmsg[0] = '\0';
if ( (argc == 2) && (strlen(argv[1])>0) &&
(strncmp(argv[1],"-help",strlen(argv[1])) == 0) ) {
Tcl_AppendResult( interp, "command syntax: \"",
"plptex x y dx dy just text", "\"",
(char *) NULL);
return TCL_ERROR;
}
if ( (!0 && 0 && (argc < (1 + 6 - 0))) ||
(!0 && !0 && (argc != (6 + 1))) ||
( 0 && (argc != 1) && (argc != (6 + 1))) ) {
Tcl_AppendResult( interp, "wrong # args: should be \"",
"plptex x y dx dy just text", "\"",
(char *) NULL);
return TCL_ERROR;
}
x = atof(argv[1+0]);
y = atof(argv[1+1]);
dx = atof(argv[1+2]);
dy = atof(argv[1+3]);
just = atof(argv[1+4]);
Tcl_DStringInit( &dstring );
Tcl_UtfToExternalDString( NULL, argv[1+5], (-1), &dstring );
text = Tcl_DStringValue( &dstring );
plptex ( x, y, dx, dy, just, text );
Tcl_DStringFree( &dstring );
if (pl_errcode != 0) {
Tcl_AppendResult(interp, errmsg, (char *) NULL);
return TCL_ERROR;
}
plflush();
return TCL_OK;
}
If this works on Linux too, then I am going to adjust it in the
generator script (otherwise I would have to add an #ifdef/#endif).
Another question:
We do support unicode/UTF-8 strings in all other cases where an
argument is a string, right? Like: plbox taking two labels.
Then I suggest that I change all occurrences where a non-ASCII
might arise (it seems superfluous for the x/y options to plbox).
>>
>> I do not see differences with examples 17 and 29 on plain Windows,
>> though.
>
> Is this a 32-bit or 64-bit result?
>
32-bits.
>>
>>>
>>> In sum, probably example 17 and 24 need some more work on Tcl for
>>> 32-bit Windows platforms (and possibly 32-bit Linux platforms) while a
>>> change of all examples 29 to shift the discontinuties slightly from
>>> the exact centre of the plot will probably solve that (32-bit Tcl?)
>>> issue. Aside from these rendering issues it looks like everything
>>> works at least on my wine version of the Windows platform, and that
>>> good result needs confirmation on a Microsoft version of the Windows
>>> platform as well.
>>
>> Example 17's differences are a bit puzzling. I have no clue yet.
>> I can reproduce differences with example 29, so that is easier.
>
> Can you clarify that last sentence which is in apparent contradiction
> with what you said about no differences for example 29 above?
>
Oops, I meant example 26.
Regards,
Arjen
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
