Re: Entity bug report (partial apology)

Partial Apology:

The bug report below was written based on the version of Amaya I have had
installed for several months, which reports itself as Version 1.4a (downloaded
as a binary).

Today, I have downloaded and built the sources for Amaya 1.4a, and the
entities work mostly as expected (ie not according to my bug report).

The ‡ and † entities both get mapped to ∗ and € gets
mapped to ∈ and ligatures seem to be getting mapped to the two component
letters, but I can live with these. All the other entities I have tried are
preserved properly.

My main concern seems to be fixed by building from the source code, so there
must be some difference between the binary and source distributions.

Thanks for your time,
  Scott Davis


> I Wrote:
> > > Recently, I wanted to create an "infinity symbol". I discovered that the SGML
> > > markup entity for the symbol is ∞ (I think I found this on the Unicode
> > > Web site (http://www.unicode.org/)). I couldn't work out how to enter unusual
> > > entities in Amaya, so I resorted to inserting it with Emacs to see if it would
> > > render correctly. It renders correctly in Amaya and MSIE 4.0, but not Netscape
> > > 4.5 or HotJava 1.1.5.
> 
> Irene replied:
> > You can insert the set of entities with the greek palette provided by the
> > Math button. The only problem is that in 1.4a version Amaya generates a span
> > around the  entity. We're fixing this bug in the next release, but today you
> > have to remove this  span by hand.
> 
> Thanks, I hadn't found this. It helps, but I still think there is a bug. I am
> using Amaya 1.4a on Solaris 2.6.
> 
> I continued:
> > > However, now I get to my bug report:
> > > 
> > > After editing the file containing ∞ in Amaya 1.4a on Solaris, the file
> > > is saved with the Yen symbol ( - ISO8859-1 code 0xA5, Unicode 0x00A5) instead
> > > of my hand-edited entity reference which should be unicode 0x221E, Symbol font
> > > code 0xA5.
> > > 
> > > The same thing has happened with other SGML entities I have tried which are
> > > not in ISO8859-1 (eg ℵ turn into ).
> > 
> > I tested that on the 1.4a version and it worked well: ∞ remains
> > ∞  after
> > a save.
> 
> I am not getting this effect on Solaris. I have now tried the following:
>   New Document
>   click on math button (Maths pallette opens)
>   click on Greek button from Math pallette (Greek alphabet window opens)
>   Click the following buttons: infinity, clubs, diamonds, hearts, spades
>   cancel Greek alphabet window
>   Done on math Pallette
>   click save button
> 
> The complete file resulting is attached. The relevent part is
> <body lang="Symbol">
> <p>
> </p>
> </body>
> Clicking reload, typing some ordinary text, saving and reloading that ended
> up with the whole file displayed in Greek.
> 
> Other experiments created a <span lang="Symbol"></span>
> 
> This is not creating the entity references, it is changing the display
> character set, and may demonstrate why the save is misbehaving for the
> entities that are being interpreted on reading.
> The file I expected would look like (this is handcrafted)
> <html>
> <head>
> <title>test 1</title>
> </head>
> <body>
> &infin;&clubs;&diams;&hearts;&spades;
> </body>
> </html>
> 
> After loading into Amaya, adding a space, and clicking save, I get
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
>    "http://www.w3.org/TR/REC-html40/loose.dtd">
> <html>
> <head>
> <title>test 1</title>
> </head>
> <body>
> 
>  
> </body>
> </html>
> 
> Amaya seems to be recognising the entities correctly, and translating them to
> the right character codes in the Symbol font, but the writing out is not
> doing the translation back to entities, but simply keeping that character
> code.
> 
> Thanks,
>   Scott
> 
> -- 
> Scott Davis					Phone: +61 8 8259 6360
> Information Technology Division,                Fax:   +61 8 8259 5619
> Defence Science and Technology Organisation
> PO Box 1500
> Salisbury, South Australia 5108		scott.davis@dsto.defence.gov.au
> 
> 

Received on Wednesday, 24 March 1999 01:56:44 UTC