TextAttribute problems
Locked
 
|
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. |
|
|
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. Confirmed. I don't know what the problem is, but I'm pretty sure it's my fault. I'll see what I can do about a fix. Dave |
|
|
In reply to this post by Chris Muller-3
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. Dave |
|
|
On 6 January 2014 23:30, David T. Lewis <[hidden email]> 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? frank > Dave |
|
|
On Sat, Jan 11, 2014 at 02:26:49PM +0000, Frank Shearar wrote:
> On 6 January 2014 23:30, David T. Lewis <[hidden email]> 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 |
|
|
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 <[hidden email]> 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 |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |