On Sat, Jan 11, 2014 at 10:00:45AM -0500, David T. Lewis wrote:
> On Sat, Jan 11, 2014 at 02:26:49PM +0000, Frank Shearar wrote:
> > On 6 January 2014 23:30, David T. Lewis <lewis at mail.msen.com> wrote:
> > > On Mon, Jan 06, 2014 at 03:24:11PM -0600, Chris Muller wrote:
> > >> I have been getting several "Object is not in the collection" errors
> > >> due to the recent removal of TextAttribute types.
> > >>
> > >> For example, try:
> > >>
> > >>    ReleaseBuilder openWelcomeWorkspaces
> > >>
> > >> I'd try to fix it myself but I wasn't involved in this change or know
> > >> what its really about.
> > >>
> > >> Help appreciated, thanks.
> > >
> > > It should be working now.
> > >
> > > I think that the situation was this:
> > >
> > > - TextFontReference was designed to work with StrikeFont fonts. It does not
> > > work with TTCFont fonts because it contains insufficient information to
> > > uniquely specify a font.
> > >
> > > - The height of a TTCFont is a float, and the height of a StrikeFont is
> > > an integer. In RunArray class>>scanFrom: this worked used to work accident
> > > because the fractional part of a font height was discarded.
> > >
> > > - When I changed RunArray class>>scanFrom: to read new TextAttribute
> > > instances from the stream, it no longer worked by accident.
> > >
> > > - Fixing TextFontReference to accept font height specifications like '20.0'
> > > in addition to '20' (allow the height to be either and integer or a float)
> > > allows the TextFontReference to be read correctly from a stream. This in
> > > turn allows the new version of RunArray class>>scanFrom: to work as expected.
> > >
> > > - TextFontReference remains broken for TTCFont fonts. This is a broader issue,
> > > and I do not know what to do about it.
> > 
> > The brokenness for TTCFonts - is that the reason behind RunArrayTest
> > >> #testScanFromTrailer's failure?
> >
> 
> No, it is not the fault of TTCFonts. But it might well be that the changes
> that I made to TextAttribute parsing have introduced this failure. I will
> look into it.
>

The test failure happens here:
  RunArray scanFrom: '(8 4 5),b,!' readStream

I am not sure if the test is wrong, the parser is wrong, or if one or
more of the writeScanOn: implementations is wrong. Probably is it at
least two out of three of the above.

RunArray class>>scanFrom: is the method that I changed recently and that
is the immediate cause of the test failure.

The original implementation of the RunArray class>>scanFrom: parsing has
a comment that suggests that space and cr characters should be skipped.
However, that actual implementation would skip any character that was not
an identifier for a TextAttribute.

The current implementaion of scanFrom: does not skip over $! characters.
I suspect that the current version is actually correct, although I am
not sure.

It may be best to relax the checks in RunArray class>>scanFrom: to skip
any unrecognized character, including $!. This is the original behavior
of the method, and although I suspect that it is not right, it is probably
better to stay compatible with the original implementation.

But I am not going to commit anything until I become less confused.

Dave