Re: glyph generation errors in the layout manager

[Fred Kiefer]

The other exception that you showed in your last mail point in the 
direction of NSURL. From a private mail I know that you used
        [attributes setObject: hyperlinkTarget
                       forKey: NSToolTipAttributeName];
to set the tool tip. It now looks like hyperlinkTarget was an NSURL and 
should have converted that to an NSString first.

Fred


On 20.07.2011 16:23, Riccardo Mottola wrote:
> Hi Fred,
>
> If I remove the "tooltip" property from the link, I don't get the error
> anymore. The tooltip didn't show up in any case (but they usually do
> work in Vespucci).
>
> Now even if I don't get exceptions, the links do not show properly
> formatted (blue and underlined), although they show, work and have the
> proper mouse cursor.
>
> I hope this helps a little.
>
> Riccardo
>
> On 07/20/11 09:26, Fred Kiefer wrote:
> > On 19.07.2011 11:45, Riccardo Mottola wrote:
> > > I just fixed the Grr parser so that it displays some atttributes
> > > extracted from HTML inside the article. Most importantly, links!!! The
> > > bug was big I wonder how it ever had worked, I'd guess no but that's
> > > strange.
> > >
> > > Anyway, now when displaying certain Articles the console gets spammed
> > > by:
> > >
> > >
> > > 2011-07-19 11:25:59.461 Grr[13239] GSHorizontalTypesetter - Glyph
> > > generation was triggered for a layout manager while the text storage it
> > > was attached to had unprocessed editing. This is not allowed. Glyph
> > > generation may be triggered only at points where calls to -beginEditing
> > > and -endEditing are balanced.
> > > 2011-07-19 11:25:59.461 Grr[13239] GSHorizontalTypesetter - Glyph
> > > generation was triggered for a layout manager while the text storage it
> > > was attached to had unprocessed editing. This is not allowed. Glyph
> > > generation may be triggered only at points where calls to -beginEditing
> > > and -endEditing are balanced.
> >
> > Could you please add a break point in line 718 of the file
> > GSLayoutManager.m and report back the back trace you get. That way we
> > should be able to understand what is going on. Most likely we have a
> > background thread that is changing the text while the gui thread is
> > trying to lay it out. I am not sure what the best way to handle this
> > could be. Maybe throw a specific exception here and handle it in the
> > text view? I don't like the idea of adding more locks to the text
> > processing.