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.

Dave