Re: Amaya 0.8a BUGs: German umlauts always uppercase et al.

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "DV" == Daniel Veillard <veillard@praslin.inrialpes.fr> writes:

    >> - - German umlaut characters are always GENERATED in their
    >> uppercased form, although Amaya displays them right when
    >> browsing a document generated by some other editor.

    DV>   I have just tried to generate them again, and it seems to
    DV> work !

    DV> I have generated lowercase A umlaut by doing :

    DV> pressing and releasing the <Alt> modifier pressing and
    DV> releasing the <A> key pressing and releasing the <"> (double
    DV> quote) key

    DV> For the capital one :

    DV> pressing and releasing the <Alt> modifier pressing the <Shift>
    DV> modifier pressing and releasing the <A> key releasing the
    DV> <Shift> modifier pressing and releasing the <"> (double quote)
    DV> key

    DV>   Could you check these sequences. Was the umlaut mapped to
    DV> another char on your keyboard (like a diacritic) ? I have
    DV> copied the sequences available from the X11R6 Compose file :

    DV>       /usr/X11R6/lib/X11/locale/iso8859-1/Compose

As I am german, I have a keyboard, wich has the german umlauts as
normal keys on it (keys nos. 0x30 ('ä', &auml;), 0x2f ('ö', &ouml;),
0x22 ('ü', &uuml;) and 0x14 ('ß', &szlig;). I use the standard
~/.Xmodmap that came with my (german) Linux Distribution, and these
are the relevant portions of the output from xkeycaps:

	!
	! This is an `xmodmap' input file for PC 102 key keyboard #1 (Linux/XFree86 German layout) keyboards.
	! Automatically generated on Wed Sep  4 13:48:17 1996 by fischer with
	! XKeyCaps 2.29; Copyright (c) 1995 Jamie Zawinski <jwz@netscape.com>.
	!
	! This file makes the following changes:
	!
	! The "§ 3 ³" key generates 3, paragraph, and threesuperior
	! The "K" key generates k, K, and Arabic_kaf
	! The "L" key generates l, L, Arabic_lam, and Greek_lamda
	! The "Alt Gr" key generates Mode_switch, and the Mod3 modifier
	
	keycode 0x14 =  ssharp          question        backslash
	keycode 0x22 =  Udiaeresis
	keycode 0x2F =  Odiaeresis
	keycode 0x30 =  Adiaeresis
	keycode 0x26 =  A
	keycode 0x3C =  period          colon
	
XEmacs, eg. always worked fine for me, treating Udiaeresis like any
other "normal" key (like 'A' above, wich is menitioned only
uppercase), getting a "udiaeresis" when pressed without the "Shift"
key, and a "Udiaeresis" when pressed with "Shift" (to be looked at
with "M-x view-lossage").

When I changed my Xmodmap to have different entries for lower and
upper (like the period / colon pair above), I could work with amaya:

	keycode 0x22 =  udiaeresis      Udiaeresis
	keycode 0x2F =  odiaeresis      Odiaeresis
	keycode 0x30 =  adiaeresis      Adiaeresis
	
So my conclusion is that maybe amaya doesn't respect environment
variables LC_CTYPE (or LC_ALL, cf. locale(7)), which I have set to
iso_8859_1 (I also tried de_DE.ISO8859-1 and ISO-8859-1 (this is the
one referenced in the locale(7) man- page)) and regards Udiaeresis not
to be a normal character and thus takes it verbatim instead of
applying case-conversion according to the "Shift" Key.

from isalpha(3):

       isalpha()
              checks for an alphabetic character; it  is  equiva-
              lent to (isupper(c) || islower(c)).
	[...]
       The details of what characters  belong  into  which  class
       depend on the current locale.  For example, isupper() will
       not recognize an A - umlaut as an uppercase letter in  the
       default C locale.

Hope this may help you and/or others.


    >> - - Sometimes the Structure View is not perfectly in sync with
    >> the WYSIWYG window. I was typing one char ahead. Waiting a few
    >> seconds did't help.

    DV>   Yes we initially decided that maintaining a strict coherency
    DV> beween views was superfluous, you just need to move the cursor
    DV> to another part to have the other views reflecting the new
    DV> value of the text. Since you're not the only one to dislike
    DV> the behaviour we will probably enable full coherency or add a
    DV> timeout. BTW current CPU are so powerfull that they are iddle
    DV> 95 % of the time.

Make it an option -- compile-time option, X-resource (better),
command-line option (better again), toggle switch in the "Views" menu
(best).

    >> - - The postscript files generated by printing to a file make
    >> my ghostview hang on the last page.

    DV>   strange, does it print anyway ?

I don't have a printer. I'll include a sample generated PS- file at
the end of this mail. Funny enough, it's only that short Error message
I always get when invoking amaya while not connected to the net. Which
leads me to another Nice-If-Changed:

- - - - Since amaya always needs at least one document to display (I know,
we already had that one), there could be a nicer way to persistently
define a different HOME_PAGE (site- wide and/or on a per- user basis)
than editing the amaya- script or setting Emvironment- Variables
(name-space-pollution): X resources and config- files like ~/.amaya.

    >> - - A document that is a concatenation of HTML documents
    >> (i.e. that contains another <HTML> section after a </HTML> tag)
    >> ends after the first part. This is probably intended, but it
    >> would be nice to be able to concatenate a number of WWW- pages
    >> into a single file without prior editing, and without losing
    >> the notion of different parts, then editing this collection and
    >> print it as one piece (with continuous and contiguous page
    >> numbering; great for manuals!). Also literate programming could
    >> be simpler this way.

    DV>   We have already do some experiments on breaking a big
    DV> dodument in small fragments, for exemple when exporting
    DV> Articles documents in Thot [1] to HTML. Splitting is
    DV> relatively easy if your document has a structure where chunks
    DV> are clearly designed. Problem is having a good merge
    DV> functionnality. It needs helps from the used or a predefined
    DV> groupping strategy. In the case of HTML designing all the
    DV> pages defining for example a documentation can be tedious for
    DV> the user and an inadequate auto-fetching strategy could bring
    DV> you the whole Web in your document and would require a large
    DV> amount of RAM :-) .

Ok, but I still think amaya should ignore "</HTML> <HTML>" pairs.

    DV> Daniel
    >> Mark Seb. Fischer

Kind regards,
	Mark 


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1
Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface

iQCVAwUBMi2stty3aoVUNlxJAQE2/QQAsqRWCy1SOIRUC0peK1xuQ3OGhliHtaci
KOYNf5OSfrOeEbrkjQPwAZdAHXXWoB1daVBDB7TFQI6o299DoUviBdagghRDfa94
2orrZmTKC1X+a6TEMA9MZo6dDphQuaRNka20thIY2gxuurX0yusnCUMJrg7mCpbJ
vywb4RuJgEI=
=v4R8
-----END PGP SIGNATURE-----

/*************************************************************************\
* Mark Sebastian Fischer          Mark.Seb.Fischer@horz.technopark.gmd.de *
* Private:                        Company: horz&schnepf                   *
*      Kirschallee 20                  Rathausallee 10                    *
*      D - 53115 Bonn (Germany)        D - 53757 Sankt Augustin (Germany) *
*      Phone: [(49) 228] 21 05 77      Phone: [(49) 2241] 20 53 06        *
*      Fax:   [(49) 228] 21 05 03      Fax:   [(49) 2241] 14-30 06        *
* PGP MD5: 26  9D  44  45  AE  15  DE  28  3B  CF  2F  1C  EA  5D  CC  E4 *
*   -  - ---  - - -  --- - --- ---    - --- -  - -  --- - -  -  - --- -   *
* It's a 106 miles to Chicago, we've got a full tank of gas,half a packet *
* of cigarettes, it's dark, and we're wearing sunglasses.  (Elwood Blues) *
\*************************************************************************/