Just to follow-up on this, since we got no negative feedback, the changes have been made and will be part of the next MITAB release.
So starting with the next release, '\n' and '\\' will not be escaped any more in string attributes and text labels returned by MITAB. We have a few other things to do in MITAB and a new release should be available in the next month or so. Daniel Canfield, Andrew wrote: > I have always why it was escaped. For my part I will have to comment out code > that translated those escape sequences into char(10) which will be nice > because then my code doesn't have to have special cases for the tab files > when I am reading in from both shapefiles and tab files in one reader. It may > break a tiny bit of my code but going forward it will be easier to maintain > so for my two cents I say change it because I will only have to comment some > lines out not re-write anything. > > -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] Behalf Of > Daniel Morissette > Sent: Friday, July 08, 2005 8:39 AM > To: [email protected] > Subject: [mitab] Use of escaped '\n' in string attributes > > > Hi, > > It has been pointed to me that the way MITAB returns newlines in escaped > "\n" format in string attribute values is not consistent with the way > other OGR drivers do things. (See quoted email from the MapServer-Dev > list below) > > Since MITAB is also used as a driver in the OGR library, it seems that > the best way to go would be to align its behavior with the behavior of > other OGR drivers, which would mean that the escaped "\n" should > actually be returned as a single ASCII-10 character in the future (which > is what is stored internally in a .DAT file). > > In the case of MIF files, the "\n" sequence from the files would also be > converted to ASCII-10 by the library. > > I realize that this is a serious change and may cause a problem to > existing apps using MITAB that expect the escaped "\n" sequence, that's > why I'm writing this, to get feedback from users. Perhaps we could also > expose a new set of EscapeString() and UnEscapeString() methods for > those who want to work with escaped versions of the strings. > > Any comments, suggestions? > > Daniel > > > > -------- Original Message -------- > Subject: Re: [UMN_MAPSERVER-DEV] OGR WRAP character > Date: Fri, 8 Jul 2005 11:09:15 -0400 > To: [EMAIL PROTECTED] > > Frank Warmerdam wrote: > >>My first thought is that the MITAB driver should not be turning char-10 >>into escaped \n format. The \n character is legal (though possibly >>occationally a nuicance) in attribute values and I don't think most other >>drivers fool with special characters like this. >> > > > So should I take this as a clear statement that it is okay (and actually > the recommended way) for an OGR driver to return strings with > non-printable characters in them? I guess that was my main question > before making a decision on what to do about the specific problem > between MITAB and MapServer. > > >>Since Daniel "owns" MITAB you guys are welcome go ahead to a >>change to the behavior if you are comfortable with it, though it might >>be nice to raise the issue on the mitab mailing list. >> > > > Still not sure what to propose for MITAB: MIF files contain '\' + 'n', > so that's what users of the lib are likely to expect. If MIF files > return one thing and TAB files return a different thing then that means > applications using MITAB need to handle both cases in a different way > which is ugly. Changing the behavior to return ASCII-10 even in the MIF > case may be the way to go, I'll have to dig and try to figure out why I > bothered implementing this escaping in the first place. yuck! > > Thanks for your input. > > Daniel Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/mitab/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
