I didn't get a reponse to the original email so resending it. If this is
not the proper mailinglist for this issue, please let me know.
In my application I use a custom label function to plot the time on the
x-axis. When the values on the y-axis are large there's a exponent label
with '(x10#u%d#d)' as label. The placement of this label seems to be
wrong; on Linux it's drawn on the right side of the y-axis inside the
plot itself, on Windows it's not drawn at all. The behaviour might be
seen with the attached patch for example 01. (Might be since the
behaviour depends on the environment it's build in.)
I tracked the issue down and created a patch to fix the issue. At least
the code now matches with the comment; The original code (plbox.c:1510)
// Assume label data is for placement of exponents if no custom
// label function is provided.
if ( plsc->label_data )
The attached patch fixes the problem for my use case, but I'm not sure
it's enough. I haven't been able to find this behaviour in the
documentation and wonder whether this behaviour is intentionally and
should be documented, or is not intended.
The documentation of the label_func argument of plslabelfunc seems to
indicate it's not intended "This is the custom label function. In order
to reset to the default labeling, set this to NULL." It doesn't mention
that the label_data also needs to be set to NULL to reset the default
behaviour of the placement of the exponent label.
The current behaviour makes it impossible to combine a custom label
function and change the placement of exponent labels. This is not
something I need, but I wonder whether it's wanted to combine this
behaviour. Another argument against the combination is that the
plslabelfunc takes a void pointer and then access the pointer as if it
points to a PLLabelDefaults structure. If the user, for example, sends a
pointer to an ingeger, it might cause accessing memory out of bounds and
can casting `random' data to a floating point value. When documented it
becomes a smaller issue, but might still catch some users by surprise.
Mark de Wever