Re: patch: SmartQuotesEnable preference item


Subject: Re: patch: SmartQuotesEnable preference item
From: Thomas Fletcher (thomasf@qnx.com)
Date: Tue Jul 18 2000 - 07:18:26 CDT


On Mon, 17 Jul 2000, WJCarpenter wrote:

> sam> What we could do is have the glyphs remapped in memory to smart
> sam> quotes, but stored in the .abw file as normal quotes. This would
> sam> have the benifits I outlined earlier.
>
> tf> While interesting, I think that you would need to have some state
> tf> knowledge that you would have to maintain between calls to the
> tf> remapGlyphs code. This state information would be a pain to have
> tf> to maintain, and I'm almost certain that doing so would introduce
> tf> some very subtle bugs.
>
> That is certainly true as remapGlyphs() is implemented today because
> it was meant to deal only with remapping a character in isolation,
> modulo some user preference items. (Let's ignore for now that
> remapGlyphs() is about weak font support, not about smart quotes.)
>
> remapGlyphs() could be re-implemented to know some context, which
> might be slightly less dodgy. I think you would only need to know
> three things to decide (modulo user preference items):
>
> 1. current character ... is it one of the 3 ASCII quotes?
> 2. thing before
> 3. thing after
>
> "Thing before" and "thing after" are either a specific character or an
> indication of an interesting break (e.g., column break, paragraph
> break, etc). This is all pretty easy if you're looking at a block of
> existing text, or a block that is being pasted in. It's a bit
> trickier to do as-the-user-types because "thing after" will soon
> change. So, rather than carrying state in remapGlyphs(), you have to
> carry it somewhere else to remember to go back and schedule the
> previously drawn glyph for a redraw in the new context.
>
> Perhaps that is the state stuff you had in mind. I agree there is a
> risk there. Above, I just wanted to sketch out a plan whereby I think
> it could be done. It is, in any case, tricky.

Yes this is precisely what I had in mind. You can't delay the
character from being mapped until you get the "thing after" and
at the same time I absolutely hate it when words start changing
under my feet (even the squiggly line occasionally tests my
patience). Of course you could always say that "the user can
turn it off in the preferences", but I'd much rather see us
focusing on other things. As you pointed out, your remapGlyphs()
code was intended for one purpose, which it does quite well.
I'd hate to see that clean code all butchered up for something
that we may want to make much more generalized in the future.
In short it isn't just about re-maping smart quotes, but also
potentially about doing on the fly spell _correction_ and other
actions that require us to to work as the user types. I think
that putting this code into remapGlyphs is the wrong place
to put it. Instead we should look to see where the squiggle
code is and if you really want to, generalize that so that
it can do squiggles, smart quote substitution, auto typo
correction (ie teh --> the automatically), automatic outline
collapsing and the like. That would seem to me to be a much
better way to spend your development time.

Of course I am but one voice of many, and it is your development
time.

Thomas
  Just because it can be done, doesn't mean it should be done.
-------------------------------------------------------------
Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf



This archive was generated by hypermail 2b25 : Tue Jul 18 2000 - 07:17:57 CDT