Branch: refs/heads/master
Home: https://github.com/Starlink/starjava
Commit: 255fb30c84b8817949d091e26c46f6a55af5a76f
https://github.com/Starlink/starjava/commit/255fb30c84b8817949d091e26c46f6a55af5a76f
Author: Mark Taylor <[log in to unmask]>
Date: 2014-08-12 (Tue, 12 Aug 2014)
Changed paths:
M ttools/src/testcases/uk/ac/starlink/ttools/task/MultiCopyTest.java
M ttools/src/testcases/uk/ac/starlink/ttools/task/VotCopyTest.java
M ttools/src/testcases/uk/ac/starlink/ttools/task/multi.vot
Log Message:
-----------
ttools: improve unit tests for unicode in VOTable
Adjust the unit tests for the votcopy task to check that columns
with datatype="unicodeChar" are encoded properly in the various
VOTable output serializations. In the existing code they are not,
leading to a complete read failure.
Commit: d40fc77649a35a4a99d1a3e9af80997483f7c744
https://github.com/Starlink/starjava/commit/d40fc77649a35a4a99d1a3e9af80997483f7c744
Author: Mark Taylor <[log in to unmask]>
Date: 2014-08-12 (Tue, 12 Aug 2014)
Changed paths:
M topcat/src/docs/sun253.xml
M ttools/src/docs/sun256.xml
M ttools/src/main/uk/ac/starlink/ttools/copy/VotCopyHandler.java
M votable/src/main/uk/ac/starlink/votable/Encoder.java
M votable/src/main/uk/ac/starlink/votable/VOSerializer.java
Log Message:
-----------
votable: fix/improve output of unicodeChar columns
When using votcopy to write a BINARY or BINARY2 serialized VOTable
in which some (non-empty) columns have datatype="unicodeChar",
there was a serious bug which meant the output was inconsistent
with the FIELD declaration (FIELD said datatype="unicodeChar",
but the output stream used 1-byte characters). This rendered the
output VOTable unreadable (reported by Peter Draper). Fixed.
Some other slight improvement to handling of unicodeChar columns too:
columns that originally had datatype="unicodeChar" (originating from
a VOTable) are now written out with the same datatype, rather than
being squashed to type char.
However, it's still a bit of a mess, partly because unicode handling
is sloppy in STIL in general, and partly because VOTable's unicodeChar
datatype value doesn't really make sense (VOTable 1.3 and earlier).
The first issue may require more work somewhere down the line,
e.g. STIL becoming aware of whether columns are Unicode or ASCII-alike,
at least for output.
The second has been acknowledged in recent VOTable discussions,
and may be resolved or improved in a future version of the VOTable
standard.
Compare: https://github.com/Starlink/starjava/compare/a3fb3f770ca7...d40fc77649a3
