Subject: Re: Insert Symbol, an apology
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Mon Apr 10 2000 - 20:40:26 CDT
On Mon, 10 Apr 2000, Paul Rohr wrote:
> [ From the never-take-a-weekend-off department. ]
>
> It's been a while since I originally peeked at Martin's patches, but IIRC
> correctly, the things which concerned me the most included:
>
> 1. Is there a plan for handling Unicode characters in this dialog? As far
> as I can tell, the current solution just handles font-specific ASCII-like
> encodings, which is likely to create compatibility problems when that
> document gets exchanged.
>
Maybe the problem is with my understanding of Unicode and abi's current
capabilities. I have only worked on the unix version of abiword whci ships
with a set of standard default fonts. As far as I can see, abiword on unix
has the capability to render unicode, but the standard distributions only
have about 16 different fonts. The "Insert Symbol" patch as it presently
stands allows one to coose any of the 256 - 32 = 234 printable chacrters
within this collection of fonts. If one adds more 256 character font sets
to the fonts directory then the "Insert Symbol" dialof will pick them up
automatically and add them to the list of fonts.
I asked a little while ago how the unix version of abi was going to
support CKJ without shipping an entire unicode font package.
> If you look at the insert symbol dialogs in Word or NT, there are two
> different capabilities offered:
>
> a. insert any unicode character which exists in a given font
>
> b. ignore encodings and just blindly insert an existing offset from a
> particular Type 1 or TrueType font
>
(b) Is what "Insert Symbol" does. You choose a font and a character from
with the font.
> In some cases, the latter option (b) may be unavoidable, since the font
> encoding is effectively gibberish, so any time you have to substitute fonts
> (for example when going to a different machine) you won't be able to read
> that content at all.
>
> Ideally, we'd be better off with option (a) where possible, since that way a
> bullet is a bullet is a bullet.
>
This is a problem already. If I grab a word document with say, an alpha
symbol, the unix version of abiword looks to see what font it came from.
The name for the font from the word document is "symbol" which the unix
version does not recognize even though there is a one for one mapping
between "Standard Symbols" and "symbol". So this problem exists already. I
can't see how to fix it without making a large fraction of the unicode
font set available by default and then hoping that the word document also
provides a unicode character.
But even more basic, the whole focus of the abi on Unix is very much
non-unicode. I had to fight with Shaw even to get him to change encodings
for "Standard Symbols" so they would show up on X11 and print OK. I don't
want to hold up this dialog until these problems are solved for unix.
This might only happen after GTK 1.4 is released. When they
are solved it should be easy to fix "Insert Symbol". As it standrads now
"Insert Symbol" will be extremely useful for 99% of our potential users.
> 2. Have the APIs been fixed to pass arguments safely and cleanly? I seem
> to recall some weirdness about passing strings, as well as something about
> usage of statics.
>
I think the strings issue has been fixed. I believe the use of static
variables to hold the previously defined character and font to make them
persistent across invocations of the dialog is valid C++. Certainly it
works with gcc which is generally picky about these things.
> 3. Is the XP/platform line drawn cleanly? How do the preview widgets work?
>
I believe the xp/platform line is quite clean. However there is a lot of
platform specific code that needs to be written. The windows people have
to solve a number of slightly non-standard problems. Like making the
graphics contaxt sensitive to mouse events. Locating mouse events within a
graphics context, handlers for key press events etc. There is nothing that
hasn't already been solved for the main view.
> 4. Finally, a total nit. Why are we passing the current font *down* into
> the view? I can understand passing it the other way (up into the dialog),
> but we don't do that either. I must be missing something here.
>
The idea is that the character and font selected by the dialog is actually
inserted into the document from within the view and that the dialog
remembers the font and character last chosen. The idea is that if one so
wishes, it is easy to insert a character from a different font set into a
document. It works like this. Suppose I want to put the symbol "Psi" into
a document to represent a Quantum Mechanical wavefunction. I type away in
"Times New Roman" then I press "cntrl-M" to get the dialog, choose
"Standard Symbols" (available from the previous invocation) choose "Psi",
it goes into the document by changing the font to "Standard Symbols"
within the view then inserting the charcter code for "Psi" and finally
changing the font back to "Times New Roman" so I can keep typing away.
The user doesn't have to toggle between fonts and the dialog gives as
default the font last used.
The code within the view looks to see if the font from the dialog is same
as the font currently chosen. If it isn't it doesn't change the font.
When the time comes to make the dialog non-model the dialog will look up
the most recently focussed view and apply the insert character and font
change logic straight on that view. Doing things this way easily
allows for doing the dialog in a non-modal way.
> bottom line
> -----------
> My initial impression was that this patch would require some rewriting to
> get it to work on other platforms, and I've continuously failed to find the
> time to do so myself.
>
I don't think it will require re-writing. All the mouse events and
key stroke processing is contained within the platform specific code.
Solving the unicode problems for unix is a seperate issue which I don't
think should delay this dialog. This dialog does nothing that a user could
not do from the keyboard within abi already. It just makes it much more
convenient.
Cheers
Martin
This archive was generated by hypermail 2b25 : Mon Apr 10 2000 - 20:41:37 CDT