[Octave-bug-tracker] [bug #32497] Matlab differences when using abbreviated PROPERTY names

[Nicholas Jankowski]

Follow-up Comment #10, bug #32497 (project octave):

new version, new update, new error. testing this in both Octave 6.2.0 and
Matlab R2020b, the non-compatibility with the comment #0 script has changed
(it appears that the package and Octave have changed a bit in the past two
years).  

TL;DR: i think bug should be closed.

running the comment #5 test scripts in Matlab produce the expected plot of the
shape of the Oregon/British Columbia coast with superimposed
latitude/longitude grid. 

running in Octave 6.2.0, the plot up to m_coast is produced, but running the
m_grid command the new error is now:


octave:14> m_grid
error: regexprep: the input string is invalid UTF-8
error: called from
    text at line 176 column 14
    m_grid at line 491 column 4


current line 491 appears to be the same line as the line 345 causing errors in
the previous comments:


for k=ik
   [rotang(k), horizk, vertk] = upright(rotang(k), horiz, vert);
  
text(xx(k),yy(k),labs{k},'horizontalalignment',horizk,'verticalalignment',vertk,
...
        'rotation',rotang(k),'fontsize',gfontsize*scl(k),'color',gcolor,...
        'tag','m_grid_xticklabel','fontname',gfontname,'parent',ax);
 end


Note that it calls 'horizontalalignment' in full.  Now, however, instead of
the ambiguous property error the error is about the call to
text(x(k),y(k),label{k}), where in Matlab I see the label contents as:


 5×1 cell array

    {' 136°W '}
    {' 132°W '}
    {' 128°W '}
    {' 124°W '}
    {' 120°W '}


in Octave, it has issues with char(176) or °. Confirming this, just running
in Octave:  


>> figure
>> text(1,2,char(176))
error: regexprep: the input string is invalid UTF-8
error: called from
    text at line 176 column 14


Is it expected to get this error message? I thought it is valid UTF-8? or is
it just the usual non-ascii character problem and it means UTF-8 usage is
invalid? 

If I break the script and delete the °, the script runs without either the
new or old errors. 

it does however, run into another apparent compatibility issue where a Matlab
command rescales the figure and hides the x-y axes leaving the map, but in
octave hiding the x-y axes hides the entire figure.  The code block in
question at line 590 is:


% Give a 1-1 aspect ratio and get rid of the matlab-provided axes stuff.


if isempty(strfind(version,'R2013b'))  % 27/Sept/13 - Handling for 2013b
provided by CB.
    set(ax,'visible','off',...
            'dataaspectratio',[1 1 1],...
            'xlim',MAP_VAR_LIST.xlims,...
            'ylim',MAP_VAR_LIST.ylims);
else
    set(ax,'visible','off',...
            'dataaspectratio',[1 1 1e16],...
            'xlim',MAP_VAR_LIST.xlims,...
            'ylim',MAP_VAR_LIST.ylims);
end


Note it runs the first 'not R2013b' block.  In Matlab, this turns off the axes
and leaves the figure contents. In octave, this turns off the whole figure. Is
that a bug? Already reported? Known behavior? 

worth noting that the comment #7 and comment #9 behaviors are unchanged.

Since this is a 10+ year old bug, the last error on using the actual package
in question is from 2013, the package no longer triggers the bug in the
title...  I think this can be closed. Unless the property ambiguity behavior
still needs to be ironed out for compatibility.

If either the regexp issue or the 'ax, visible, off' issue are new and
unreported, they can become other bugs. 

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?32497>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/