scrollkeeper-devel — Developer discussion list for ScrollKeeper

Re: [Scrollkeeper-devel] Re: Migration to libxml2

[Laszlo K. <las...@su...>]

Karl Eichwalder wrote:
>=20
> L=E1szl=F3 Kov=E1cs <las...@Su...> writes:
>=20
> > I tried to build OpenSP on both Solaris and Linux and I failed becaus=
e
> > of some C++ related problem coming from the source.
>=20
> For the moment and for evalution purposes you can go for the "old" or
> "original" sp package (www.jclark.com).

Same problem, although I can build sx or osx, but not the entire SP or
OpenSP. Nsgmls seems to cause problems. Here are the error messages:

c++ -fno-implicit-templates -O2 -ansi   -I. -I./../include=20
-DSP_HAVE_BOOL -DSP_ANSI_CLASS_INST -DSP_MULTI_BYTE  -c nsgmls.cxx
nsgmls.cxx: In method `void XRastEventHandler::message (MessageEvent=20
*)':
../include/Message.h:134: `class Messenger' is inaccessible
nsgmls.cxx:60: within this context
nsgmls.cxx: In method `void XRastEventHandler::truncateOutput ()':
../include/Message.h:134: `class Messenger' is inaccessible
nsgmls.cxx:61: within this context
nsgmls.cxx: In method `void XRastEventHandler::allLinkTypesActivated=20
()':
../include/Message.h:134: `class Messenger' is inaccessible
nsgmls.cxx:62: within this context
nsgmls.cxx: At top level:
../include/Message.h:134: `class Messenger' is inaccessible
nsgmls.cxx:64: within this context
../include/Message.h:134: `class Messenger' is inaccessible
nsgmls.cxx:64: within this context
../include/Message.h:134: `class Messenger' is inaccessible
nsgmls.cxx:66: within this context
../include/Message.h:134: `class Messenger' is inaccessible
nsgmls.cxx:66: within this context
../include/Message.h:134: `class Messenger' is inaccessible
nsgmls.cxx:67: within this context
../include/Message.h:134: `class Messenger' is inaccessible
nsgmls.cxx:67: within this context
../include/Message.h:134: `class Messenger' is inaccessible
nsgmls.cxx:68: within this context
../include/Message.h:134: `class Messenger' is inaccessible
nsgmls.cxx:68: within this context
../include/Message.h:134: `class Messenger' is inaccessible
nsgmls.cxx:69: within this context
../include/Message.h:134: `class Messenger' is inaccessible
nsgmls.cxx:69: within this context
../include/Message.h:134: `class Messenger' is inaccessible
nsgmls.cxx:70: within this context
../include/Message.h:134: `class Messenger' is inaccessible
nsgmls.cxx:70: within this context
nsgmls.cxx: In method `XRastEventHandler::XRastEventHandler (SgmlParser=20
*, const char *, const StringC &, const OutputCodingSystem *,=20
CmdLineApp *, Messenger *)':
../include/Message.h:134: `class Messenger' is inaccessible
nsgmls.cxx:220: within this context

I compile with gcc 2.96 which is good enough according to the web site.
I dont seem to be able to go past these messages.

Laszlo




>=20
> > On the other hand sgml2xml seemed extremely poorly documented, I coul=
dnt
> > really figure out how to use it. Maybe it needs more looking.
>=20
> Maybe, this help:
>=20
>     http://www.jclark.com/sp/sx.htm
>=20
> sgml2xml is renamed from 'sx' to avoid a namespace clash with 'sx' (par=
t
> of the rzsz package, modem related tools).
>=20
> > If the SGML encoding issue takes a long time to be sorted, we might w=
ant
> > to consider separate releases for SGML and XML i18n support. The i18n
> > improvements work for XML that I worked on was finished a couple of d=
ays
> > ago and the SGML encoding issue is the only remaining problem right n=
ow.
>=20
> Sounds okay to me (but I'm not deeply involved in the scrollkeeper
> issues at the moment).
>=20
> --
> work : ke...@su...                          |                   ,__o
>      : http://www.suse.de/~ke/             |                 _-\_<,
> home : ke...@gm...                     |                (*)/'(*)
>=20
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> http://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel

Re: [Scrollkeeper-devel] extracted index

[Mary D. <Mar...@Su...>]

Hi

From the stylesheet point of view, if we get the main entry for duplicate i=
ndex=20
terms correct, the see/seealso references will follow.

So, to recap, here's an example of the problem:
- there are multiple sections in the document indexed by the term "Panel". =
These=20
sections have the identifiers idx-a2, idx-a5, idx-a9. There are also a numb=
er of=20
see/seealso references to "Panel"
- under the current stylesheet structure this would result in the index ent=
ry
  <primary>
    <title linkid=3D"idx-a2" indexid=3D"id10715">Panel</title>
    <title linkid=3D"idx-a5" indexid=3D"id10715">Panel</title>
    <title linkid=3D"idx-a9" indexid=3D"id10715">Panel</title>
   =20
- the following solution appealed, but unfortunately ID and IDREFs as eleme=
nt=20
content is illegal :-)
<primary>
    <title>Panel</title>
    <linkid>idx-a2</linkid>
    <linkid>idx-a5</linkid>
    <linkid>idx-a9</linkid>
    <indexid>id10715</indexid>
   =20
Does anyone have any suggestions on the best way of presenting multiple=20
occurences of an indexterm??

cheers
Mary

> Subject: Re: [Scrollkeeper-devel] extracted index
> From: Gregory Leblanc <gle...@cu...>
> To: scr...@li...
> Mime-Version: 1.0
> X-BeenThere: scr...@li...
> X-Mailman-Version: 2.0.5
> List-Help:=20
<mailto:scr...@li...?subject=3Dhelp>
> List-Post: <mailto:scr...@li...>
> List-Subscribe:=20
<http://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel>,=20
<mailto:scr...@li...?subject=3Dsubscrib=
e>
> List-Id: <scrollkeeper-devel.lists.sourceforge.net>
> List-Unsubscribe:=20
<http://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel>,=20
<mailto:scr...@li...?subject=3Dunsubscr=
ibe>
> List-Archive: <http://lists.sourceforge.net/archives//scrollkeeper-devel/=
>
> Date: 24 May 2001 10:47:11 -0700
>=20
> On 24 May 2001 18:25:06 +0100, L=E1szl=F3 Kov=E1cs wrote:
> > Gregory Leblanc wrote:
> > >=20
> > > On 24 May 2001 16:37:59 +0100, Mary Dwyer wrote:
> > > > Laszlo Kovacs wrote:
> > > > > >
> > > > > > 2. If an indexterm occurs more than once in the original docume=
nt=20
then will
> > > > > > result in a duplicate entry such as this eg.
> > > > > >  <primary>
> > > > > >     <title linkid=3D"idx-a2" id=3D"id10715">Panel</title>
> > > > > >     <title linkid=3D"idx-a9" id=3D"id10715">Panel</title>
> > > > > >
> > > > > >     - this is not ideal, but not sure how to get round this.
> > > > > We probably need to find some solution for this. Is this like the=
re=20
are
> > > > > actually two different Panel descriptions in the text? Because if=
 yes
> > > > > then the document is probably incorrectly written.
> > > >
> > > > - yes, it's because there are two indexterm entries in the original=
=20
document as
> > > > follows:
> > > > <indexterm id=3D"idx-a2"><primary>Panel</primary></indexterm>
> > > > <indexterm id=3D"idx-a9"><primary>Panel</primary></indexterm>
> > > >
> > > > granted, in a correctly written help document this shouldn't occur =
...
> > >=20
> > > That's clearly not correct.  Open up a book that you have which conta=
ins
> > > an index, and you'll see a very large number of index terms that show=
 up
> > > on multiple pages.  Usually something like
> > >=20
> > > Cats, Big.... 13, 25, 256
> > >=20
> > > So this is not a error in the document, as far as I'm concerned.
> > >     Greg
> >=20
> > Yeah, I was probably to tired. It is correct of course. It raises a
> > couple of issues though.
> >=20
> > 1. I wonder how we implement this in the GUI.
>=20
> Dunno, I'm not a GUI designer.  :-)
>=20
> > 2. If we have a See Also: Panel, then to which Panel definition we jump=
.
>=20
> Ah, that one is easy (erm, I think it's easy)!  You don't like to an
> entry in the document, you link the the Index entry for the Panel.
> Didn't GNOME recruit some indexing professionals to do some volunteer
> work?  Can we sucker^W volunteer them for this discussion?
>     Greg
>=20
> --=20
> Troll, troll, troll your post
> Gently down the feed
> Merrily, merrily troll along
> A life is what you need...
>=20
>=20
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> http://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel

~ I speak for myself, not for my employer ~
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D
Mary Dwyer
Desktop Applications & Middleware Grp
Sun Microsystems Ireland
Tel: +353-1-8199222 (xt 19222)
Fax: +353-1-8199078
email: mar...@ir...
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D

Re: [Scrollkeeper-devel] extracted index

[<las...@su...>]

> > 2. If we have a See Also: Panel, then to which Panel definition we jump.
> 
> Ah, that one is easy (erm, I think it's easy)!  You don't like to an
> entry in the document, you link the the Index entry for the Panel.
> Didn't GNOME recruit some indexing professionals to do some volunteer
> work?  Can we sucker^W volunteer them for this discussion?
Ah, I was thinking more from a GUI, usability point of view. 

laszlo

Re: [Scrollkeeper-devel] Re: Migration to libxml2

[Dan M. <d-...@uc...>]

On 24 May 2001, Karl Eichwalder wrote:

> L=E1szl=F3 Kov=E1cs <las...@Su...> writes:
>
> > I tried to build OpenSP on both Solaris and Linux and I failed becaus=
e
> > of some C++ related problem coming from the source.
>
> For the moment and for evalution purposes you can go for the "old" or
> "original" sp package (www.jclark.com).
>
> > On the other hand sgml2xml seemed extremely poorly documented, I coul=
dnt
> > really figure out how to use it. Maybe it needs more looking.
>
> Maybe, this help:
>
>     http://www.jclark.com/sp/sx.htm
>
> sgml2xml is renamed from 'sx' to avoid a namespace clash with 'sx' (par=
t
> of the rzsz package, modem related tools).

Also:

http://www.they.com/doc/sp

http://www.they.com/doc/sp/sx.htm

This is very similar to the Karl's link.

Dan

Re: [Scrollkeeper-devel] Re: Migration to libxml2

[Dan M. <d-...@uc...>]

On Thu, 24 May 2001, L=E1szl=F3 Kov=E1cs wrote:

> If the SGML encoding issue takes a long time to be sorted, we might wan=
t
> to consider separate releases for SGML and XML i18n support. The i18n
> improvements work for XML that I worked on was finished a couple of day=
s
> ago and the SGML encoding issue is the only remaining problem right now.

I'm hoping the SGML encoding issue won't take a long time to resolve, but
I may be wrong.

I am reluctant to make any ScrollKeeper release, even an unstable
development release, which breaks backward compatibility with SGML docs.
Inevitably people will download it and break their system.  Or even worse=
,
somebody may ship it as an update or in their distribution and break lots
of people's systems.

I guess if we have a reason to ship a development version like this, we
could give it a scary release name with "alpha" in the version.

Dan

Re: [Scrollkeeper-devel] extracted index

[Gregory L. <gle...@cu...>]

On 24 May 2001 18:25:06 +0100, László Kovács wrote:
> Gregory Leblanc wrote:
> > 
> > On 24 May 2001 16:37:59 +0100, Mary Dwyer wrote:
> > > Laszlo Kovacs wrote:
> > > > >
> > > > > 2. If an indexterm occurs more than once in the original document then will
> > > > > result in a duplicate entry such as this eg.
> > > > >  <primary>
> > > > >     <title linkid="idx-a2" id="id10715">Panel</title>
> > > > >     <title linkid="idx-a9" id="id10715">Panel</title>
> > > > >
> > > > >     - this is not ideal, but not sure how to get round this.
> > > > We probably need to find some solution for this. Is this like there are
> > > > actually two different Panel descriptions in the text? Because if yes
> > > > then the document is probably incorrectly written.
> > >
> > > - yes, it's because there are two indexterm entries in the original document as
> > > follows:
> > > <indexterm id="idx-a2"><primary>Panel</primary></indexterm>
> > > <indexterm id="idx-a9"><primary>Panel</primary></indexterm>
> > >
> > > granted, in a correctly written help document this shouldn't occur ...
> > 
> > That's clearly not correct.  Open up a book that you have which contains
> > an index, and you'll see a very large number of index terms that show up
> > on multiple pages.  Usually something like
> > 
> > Cats, Big.... 13, 25, 256
> > 
> > So this is not a error in the document, as far as I'm concerned.
> >     Greg
> 
> Yeah, I was probably to tired. It is correct of course. It raises a
> couple of issues though.
> 
> 1. I wonder how we implement this in the GUI.

Dunno, I'm not a GUI designer.  :-)

> 2. If we have a See Also: Panel, then to which Panel definition we jump.

Ah, that one is easy (erm, I think it's easy)!  You don't like to an
entry in the document, you link the the Index entry for the Panel.
Didn't GNOME recruit some indexing professionals to do some volunteer
work?  Can we sucker^W volunteer them for this discussion?
    Greg

-- 
Troll, troll, troll your post
Gently down the feed
Merrily, merrily troll along
A life is what you need...

[Scrollkeeper-devel] Re: Migration to libxml2

[Karl E. <ke...@gm...>]

L=E1szl=F3 Kov=E1cs <las...@Su...> writes:

> I tried to build OpenSP on both Solaris and Linux and I failed because
> of some C++ related problem coming from the source.

For the moment and for evalution purposes you can go for the "old" or
"original" sp package (www.jclark.com).

> On the other hand sgml2xml seemed extremely poorly documented, I couldnt
> really figure out how to use it. Maybe it needs more looking.

Maybe, this help:

    http://www.jclark.com/sp/sx.htm

sgml2xml is renamed from 'sx' to avoid a namespace clash with 'sx' (part
of the rzsz package, modem related tools).

> If the SGML encoding issue takes a long time to be sorted, we might want
> to consider separate releases for SGML and XML i18n support. The i18n
> improvements work for XML that I worked on was finished a couple of days
> ago and the SGML encoding issue is the only remaining problem right now.

Sounds okay to me (but I'm not deeply involved in the scrollkeeper
issues at the moment).

--=20
work : ke...@su...                          |                   ,__o
     : http://www.suse.de/~ke/             |                 _-\_<,
home : ke...@gm...                     |                (*)/'(*)

Re: [Scrollkeeper-devel] extracted index

[<las...@su...>]

Gregory Leblanc wrote:
> 
> On 24 May 2001 16:37:59 +0100, Mary Dwyer wrote:
> > Laszlo Kovacs wrote:
> > > >
> > > > 2. If an indexterm occurs more than once in the original document then will
> > > > result in a duplicate entry such as this eg.
> > > >  <primary>
> > > >     <title linkid="idx-a2" id="id10715">Panel</title>
> > > >     <title linkid="idx-a9" id="id10715">Panel</title>
> > > >
> > > >     - this is not ideal, but not sure how to get round this.
> > > We probably need to find some solution for this. Is this like there are
> > > actually two different Panel descriptions in the text? Because if yes
> > > then the document is probably incorrectly written.
> >
> > - yes, it's because there are two indexterm entries in the original document as
> > follows:
> > <indexterm id="idx-a2"><primary>Panel</primary></indexterm>
> > <indexterm id="idx-a9"><primary>Panel</primary></indexterm>
> >
> > granted, in a correctly written help document this shouldn't occur ...
> 
> That's clearly not correct.  Open up a book that you have which contains
> an index, and you'll see a very large number of index terms that show up
> on multiple pages.  Usually something like
> 
> Cats, Big.... 13, 25, 256
> 
> So this is not a error in the document, as far as I'm concerned.
>     Greg

Yeah, I was probably to tired. It is correct of course. It raises a
couple of issues though.

1. I wonder how we implement this in the GUI.
2. If we have a See Also: Panel, then to which Panel definition we jump.

Laszlo

Re: [Scrollkeeper-devel] extracted index

[Gregory L. <gle...@cu...>]

On 24 May 2001 16:37:59 +0100, Mary Dwyer wrote:
> Laszlo Kovacs wrote:
> > > 
> > > 2. If an indexterm occurs more than once in the original document then will
> > > result in a duplicate entry such as this eg.
> > >  <primary>
> > >     <title linkid="idx-a2" id="id10715">Panel</title>
> > >     <title linkid="idx-a9" id="id10715">Panel</title>
> > > 
> > >     - this is not ideal, but not sure how to get round this.
> > We probably need to find some solution for this. Is this like there are
> > actually two different Panel descriptions in the text? Because if yes
> > then the document is probably incorrectly written. 
> 
> - yes, it's because there are two indexterm entries in the original document as 
> follows:
> <indexterm id="idx-a2"><primary>Panel</primary></indexterm>
> <indexterm id="idx-a9"><primary>Panel</primary></indexterm>
> 
> granted, in a correctly written help document this shouldn't occur ...

That's clearly not correct.  Open up a book that you have which contains
an index, and you'll see a very large number of index terms that show up
on multiple pages.  Usually something like

Cats, Big.... 13, 25, 256

So this is not a error in the document, as far as I'm concerned.
    Greg

-- 
Troll, troll, troll your post
Gently down the feed
Merrily, merrily troll along
A life is what you need...

Re: [Scrollkeeper-devel] extracted index

[Mary D. <Mar...@Su...>]

Laszlo Kovacs wrote:
> > 
> > 2. If an indexterm occurs more than once in the original document then will
> > result in a duplicate entry such as this eg.
> >  <primary>
> >     <title linkid="idx-a2" id="id10715">Panel</title>
> >     <title linkid="idx-a9" id="id10715">Panel</title>
> > 
> >     - this is not ideal, but not sure how to get round this.
> We probably need to find some solution for this. Is this like there are
> actually two different Panel descriptions in the text? Because if yes
> then the document is probably incorrectly written. 

- yes, it's because there are two indexterm entries in the original document as 
follows:
<indexterm id="idx-a2"><primary>Panel</primary></indexterm>
<indexterm id="idx-a9"><primary>Panel</primary></indexterm>

granted, in a correctly written help document this shouldn't occur ...

> 
> 
> > 3.  ids are generated within the index to provide internal links for see and
> >     seealso references. For example, where "Main Menu, Example" is an index
> > entry, and there is a see reference from "Chapter, Example" to "Main Menu,
> > Example" the output will be as follows:
> > 
> > <primary>
> >     <title>Chapter</title>
> >     <secondary>
> >       <title>Example</title>
> >       <see id="id10791">Main Menu, Example</see>
> >     </secondary>
> >   </primary>
> >   <primary>
> >     <title>Main Menu</title>
> >     <secondary>
> >       <title linkid="idx-a3" id="id10791">Example</title>
> >     </secondary>
> >   </primary>
> 
> Isnt there a restriction that id attributes have to be unique throughout
> the document? If it is then we will need to name the "id" attribute
> something else.

- ok, can name it something else

>  
> >  In order to be able to match the <see>/<seealso> content to the correct 
index
> > term I need to be able to assume the <see>/<seealso> content will be 
structured
> > in a set way, ie primary, secondary, tertiary (each term seperated by a 
comma
> > and a space - or whatever, once it is consistent).
> This might be a problem considering the variety of sources documents are
> coming from. Why is this needed?

- it's due to the way I'm generating the ids. In the above example when the 
stylesheet is outputing the Main Menu, Example entry it generates an id and 
outputs it (id10791). Then when the <see> entry (Chapter, Example) is being 
output, need to be able to match the <see> content to the correct indexterm. 
This is done by means of keys, so need to know how the <see>content is written 
in order to construct the keys. ...... If this restriction is an issue I can do 
some more investigation - may be able to solve it using the translate function 
to eliminate commas, spaces for the key ....


Mary
 
> 
> Laszlo

~ I speak for myself, not for my employer ~
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mary Dwyer
Desktop Applications & Middleware Grp
Sun Microsystems Ireland
Tel: +353-1-8199222 (xt 19222)
Fax: +353-1-8199078
email: mar...@ir...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: [Scrollkeeper-devel] extracted index

[<las...@Su...>]

Mary Dwyer wrote:
> 
> hi
> 
> attached is an example of an index extracted using the stylesheet I've written
> for scrollkeeper.  I'd appreciate if you could have a look at it and provide
> some feedback.
> 
> A few issues to note:
> 1. only dealing with indexterms from the original document that include an "id"
> or "zone" attribute (in order to provide anchors back to the original document)
> 
> 2. If an indexterm occurs more than once in the original document then will
> result in a duplicate entry such as this eg.
>  <primary>
>     <title linkid="idx-a2" id="id10715">Panel</title>
>     <title linkid="idx-a9" id="id10715">Panel</title>
> 
>     - this is not ideal, but not sure how to get round this.
We probably need to find some solution for this. Is this like there are
actually two different Panel descriptions in the text? Because if yes
then the document is probably incorrectly written. 


> 3.  ids are generated within the index to provide internal links for see and
>     seealso references. For example, where "Main Menu, Example" is an index
> entry, and there is a see reference from "Chapter, Example" to "Main Menu,
> Example" the output will be as follows:
> 
> <primary>
>     <title>Chapter</title>
>     <secondary>
>       <title>Example</title>
>       <see id="id10791">Main Menu, Example</see>
>     </secondary>
>   </primary>
>   <primary>
>     <title>Main Menu</title>
>     <secondary>
>       <title linkid="idx-a3" id="id10791">Example</title>
>     </secondary>
>   </primary>

Isnt there a restriction that id attributes have to be unique throughout
the document? If it is then we will need to name the "id" attribute
something else.
 
>  In order to be able to match the <see>/<seealso> content to the correct index
> term I need to be able to assume the <see>/<seealso> content will be structured
> in a set way, ie primary, secondary, tertiary (each term seperated by a comma
> and a space - or whatever, once it is consistent).
This might be a problem considering the variety of sources documents are
coming from. Why is this needed?

Laszlo

Re: [Scrollkeeper-devel] Re: Migration to libxml2

[<las...@Su...>]

Dan Mueth wrote:
> =

> On 22 May 2001, Karl Eichwalder wrote:
> =

> > L=E1szl=F3 Kov=E1cs <las...@su...> writes:
> >
> > > > (now we moved to XML and UTF-8 so this is history)
> > > Happy people:-) I wonder if it could be made history for Gnome too.=

> >
> > No need to "move" -- just delegate:
> >
> >     Don't install SGML files but "convert" them at installation time =
to
> >     XML (sgmlnorm and s2x can do wonders).  Proposed earlier by me.
> =

> Karl - Thanks for the suggestion :)
> =

> This may be a really nice way to circumvent the encoding issues and
> support SGML documents without much work.
> =

> Does anybody know exactly what happens w/r/t encodings when we do
> something like:
>    sgml2xml -b UTF-8 foo.sgml > foo.xml
> =

> It looks like this uses the encoding detection in SP to convert from an=

> arbitrary unknown encoding to UTF?
> =

> Does anybody see any problems with using a call like this in ScrollKeep=
er
> to convert any SGML docs to XML for further processing by libxml2/xslt =
in
> ScrollKeeper?
> =

> This way we can keep our SGML support without having to do much work or=

> add bloat to ScrollKeeper or libxml2.
> =

> Dan

I tried to build OpenSP on both Solaris and Linux and I failed because
of some C++ related problem coming from the source. =


On the other hand sgml2xml seemed extremely poorly documented, I couldnt
really figure out how to use it. Maybe it needs more looking.

If the SGML encoding issue takes a long time to be sorted, we might want
to consider separate releases for SGML and XML i18n support. The i18n
improvements work for XML that I worked on was finished a couple of days
ago and the SGML encoding issue is the only remaining problem right now.

Laszlo

[Scrollkeeper-devel] extracted index

[Mary D. <Mar...@Su...>]

hi

attached is an example of an index extracted using the stylesheet I've written 
for scrollkeeper.  I'd appreciate if you could have a look at it and provide 
some feedback.

A few issues to note:
1. only dealing with indexterms from the original document that include an "id" 
or "zone" attribute (in order to provide anchors back to the original document)

2. If an indexterm occurs more than once in the original document then will 
result in a duplicate entry such as this eg.
 <primary>
    <title linkid="idx-a2" id="id10715">Panel</title>
    <title linkid="idx-a9" id="id10715">Panel</title>
    
    - this is not ideal, but not sure how to get round this.
    
3.  ids are generated within the index to provide internal links for see and
    seealso references. For example, where "Main Menu, Example" is an index 
entry, and there is a see reference from "Chapter, Example" to "Main Menu, 
Example" the output will be as follows:

<primary>
    <title>Chapter</title>
    <secondary>
      <title>Example</title>
      <see id="id10791">Main Menu, Example</see>
    </secondary>
  </primary>
  <primary>
    <title>Main Menu</title>
    <secondary>
      <title linkid="idx-a3" id="id10791">Example</title>
    </secondary>
  </primary>
 
 
 In order to be able to match the <see>/<seealso> content to the correct index 
term I need to be able to assume the <see>/<seealso> content will be structured 
in a set way, ie primary, secondary, tertiary (each term seperated by a comma 
and a space - or whatever, once it is consistent).
 
 
 cheers
 Mary

p.s originally sent this mail to the alias with a too large attachment ....

~ I speak for myself, not for my employer ~
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mary Dwyer
Desktop Applications & Middleware Grp
Sun Microsystems Ireland
Tel: +353-1-8199222 (xt 19222)
Fax: +353-1-8199078
email: mar...@ir...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

[Scrollkeeper-devel] Re: Migration to libxml2

[Karl E. <ke...@gm...>]

Dan Mueth <d-...@uc...> writes:

> Karl - Thanks for the suggestion :)

I'm always at yous disposal ;)

> This may be a really nice way to circumvent the encoding issues and
> support SGML documents without much work.
> 
> Does anybody know exactly what happens w/r/t encodings when we do
> something like:
>    sgml2xml -b UTF-8 foo.sgml > foo.xml

Sorry, don't know (it works for iso-8859-1).

> It looks like this uses the encoding detection in SP to convert from an
> arbitrary unknown encoding to UTF?

Maybe, proprocessing with recode/iconv is needed.  The writer should
store the encoding somewhere (inside of a PI or a comment).

> Does anybody see any problems with using a call like this in ScrollKeeper
> to convert any SGML docs to XML for further processing by libxml2/xslt in
> ScrollKeeper?

No :)

-- 
work : ke...@su...                          |                   ,__o
     : http://www.suse.de/~ke/             |                 _-\_<,
home : ke...@gm...                     |                (*)/'(*)

Re: [Scrollkeeper-devel] Re: Migration to libxml2

[Dan M. <d-...@uc...>]

On 22 May 2001, Karl Eichwalder wrote:

> L=E1szl=F3 Kov=E1cs <las...@su...> writes:
>
> > > (now we moved to XML and UTF-8 so this is history)
> > Happy people:-) I wonder if it could be made history for Gnome too.
>
> No need to "move" -- just delegate:
>
>     Don't install SGML files but "convert" them at installation time to
>     XML (sgmlnorm and s2x can do wonders).  Proposed earlier by me.

Karl - Thanks for the suggestion :)

This may be a really nice way to circumvent the encoding issues and
support SGML documents without much work.

Does anybody know exactly what happens w/r/t encodings when we do
something like:
   sgml2xml -b UTF-8 foo.sgml > foo.xml

It looks like this uses the encoding detection in SP to convert from an
arbitrary unknown encoding to UTF?

Does anybody see any problems with using a call like this in ScrollKeeper
to convert any SGML docs to XML for further processing by libxml2/xslt in
ScrollKeeper?

This way we can keep our SGML support without having to do much work or
add bloat to ScrollKeeper or libxml2.

Dan

Re: [Scrollkeeper-devel] Migration to libxml2

[Eric B. <e.b...@no...>]

Le Wednesday 23 May 2001 18:18, Norman Walsh a =E9crit :
> | > At KDE we assumed that <book lang=3D"ru"> induced koi-8r encoding, =
<book
> | > lang=3D"fr"> induced iso-8859-15 encoding, etc.
>
> It'll never fly. There's nothing about writing in French that requires
> ISO Latin 1, or Russian that requires KOI-8r.

I said it was a hack, and it was valid only into KDE's context where we k=
new=20
each other's usual encoding  ;-)


--=20
+----------------------------------------------------------------------+
| =C9ric Bischoff                              mailto:e.b...@no... =
|
+----------------------------------------------------------------------+

Re: [Scrollkeeper-devel] Migration to libxml2

[Norman W. <Nor...@ea...>]

/ László Kovács <las...@Su...> was heard to say:
| > At KDE we assumed that <book lang="ru"> induced koi-8r encoding, <book
| > lang="fr"> induced iso-8859-15 encoding, etc.
| > 
| Yes, this could be a way. To put together a table with locales and
| corresponding probable encodings. I dont know thought how libxml2 reacts
| if we assume an encoding different from UTF-8, but the input file is
| actually UTF-8.
| 
| Any thoughts about this method to solve the problem?

It'll never fly. There's nothing about writing in French that requires
ISO Latin 1, or Russian that requires KOI-8r.

                                        Be seeing you,
                                          norm

-- 
Nor...@Su...   | One does what one is; one becomes what one
XML Standards Engineer | does.--Robert Musil
Technology Dev. Group  | 
Sun Microsystems, Inc. | 

[Scrollkeeper-devel] Re: language list

[Pablo S. <pa...@ma...>]

Kaixo!

On Wed, May 23, 2001 at 01:30:27PM +0100, L=E1szl=F3 Kov=E1cs wrote:
> Hi,
>=20
> Another crosspost ...
>=20
> I am trying to implement a similar language list mechanism as in
> gnome-libs/gnome_i18n_get_language_list(). This is about querying
> LC_ALL, LC_MESSAGES and LANG in this order,

It should be LANGUAGE, LC_ALL, LC_MESSAGES and LANG in that order.
LANGUAGE is a real list (others accept only one value)

> in fact setlocale() does
> this all for me. My problem is that although this is implemented in
> gnome-libs() Linux does not seem to like language lists in these
> variables.

Indeed. LC_*, and LANG only accept a locale value.
The real variable to look for language lists is LANGUAGE.
It is not used by setlocale(), but by gettext() family of functions.
Note that LANGUAGE alone is not enough, as it defines languages, but
not the encodings (eg, for language 'ru' (Russian) should it be displayed=
 in
koi8-r, iso-859-5, cp1251, utf-8,...); that is the role of setlocale()
to define that.

> returns C, although the environment variables are set to the list. I
> dont know what am I doing wrong. On the other hand on Solaris setting
> these variables to a language list is illegal, it can be set to one
> locale only and only to one of those that are installed.

So it is on GNU/Linux.
Only LANGUAGE (a GNU extension) allows a list.

> Any thoughts?

Hope that helps.

More info on LANGUAGE can be get from GNU libc info pages.
=20
> Laszlo
>=20
> _______________________________________________
> gnome-i18n mailing list
> gno...@gn...
> http://mail.gnome.org/mailman/listinfo/gnome-i18n

--=20
Ki =E7a vos v=E5ye b=E9n,
Pablo Saratxaga

http://www.srtxg.easynet.be/		PGP Key available, key ID: 0x8F0E4975

Re: [Scrollkeeper-devel] Migration to libxml2

[<las...@Su...>]

> At KDE we assumed that <book lang="ru"> induced koi-8r encoding, <book
> lang="fr"> induced iso-8859-15 encoding, etc.
> 
Yes, this could be a way. To put together a table with locales and
corresponding probable encodings. I dont know thought how libxml2 reacts
if we assume an encoding different from UTF-8, but the input file is
actually UTF-8.

Any thoughts about this method to solve the problem?

Laszlo

[Scrollkeeper-devel] Re: language list

[<las...@Su...>]

Christian Rose wrote:
> =

> L=E1szl=F3 Kov=E1cs wrote:
> > I am trying to implement a similar language list mechanism as in
> > gnome-libs/gnome_i18n_get_language_list(). This is about querying
> > LC_ALL, LC_MESSAGES and LANG in this order, in fact setlocale() does
> > this all for me. My problem is that although this is implemented in
> > gnome-libs() Linux does not seem to like language lists in these
> > variables. I tried to set some lists, but my setlocale() call still
> > returns C, although the environment variables are set to the list. I
> > dont know what am I doing wrong. On the other hand on Solaris setting=

> > these variables to a language list is illegal, it can be set to one
> > locale only and only to one of those that are installed.
> =

> I *beleive* this is the same for Linux. I have never seen a system with=

> a language list in the LC or LANG variables myself, and it wouldn't
> surprise me if it isn't supported. But I don't know for sure. The glibc=

> manual (http://www.gnu.org/manual/glibc/html_mono/libc.html#SEC111)
> mentions that language (locale) lists should be possible in the LANGUAG=
E
> variable though:
> =

>         "When developing the message translation functions it was felt
>         that the functionality provided by the variables above is not
>         sufficient. For example, it should be possible to specify more
>         than one locale name. Take a Swedish user who better speaks
>         German than English, and a program whose messages are output
>         in English by default. It should be possible to specify that
>         the first choice of language is Swedish, the second German,
>         and if this also fails to use English. This is possible with
>         the variable LANGUAGE. For further description of this GNU
>         extension see section User influence on gettext
>         (http://www.gnu.org/manual/glibc/html_mono/libc.html#SEC137)."
> =

> Christian

Yes, this is the answer probably, I also discovered it in the meantime.

Thanks,

Laszlo

[Scrollkeeper-devel] Re: language list

[Christian R. <me...@me...>]

L=E1szl=F3 Kov=E1cs wrote:
> I am trying to implement a similar language list mechanism as in
> gnome-libs/gnome_i18n_get_language_list(). This is about querying
> LC_ALL, LC_MESSAGES and LANG in this order, in fact setlocale() doe=
s
> this all for me. My problem is that although this is implemented in
> gnome-libs() Linux does not seem to like language lists in these
> variables. I tried to set some lists, but my setlocale() call still
> returns C, although the environment variables are set to the list. =
I
> dont know what am I doing wrong. On the other hand on Solaris setti=
ng
> these variables to a language list is illegal, it can be set to one
> locale only and only to one of those that are installed.

I *beleive* this is the same for Linux. I have never seen a system wi=
th
a language list in the LC or LANG variables myself, and it wouldn't
surprise me if it isn't supported. But I don't know for sure. The gli=
bc
manual (http://www.gnu.org/manual/glibc/html_mono/libc.html#SEC111)
mentions that language (locale) lists should be possible in the LANGU=
AGE
variable though:

=09"When developing the message translation functions it was felt
=09that the functionality provided by the variables above is not
=09sufficient. For example, it should be possible to specify more
=09than one locale name. Take a Swedish user who better speaks
=09German than English, and a program whose messages are output
=09in English by default. It should be possible to specify that
=09the first choice of language is Swedish, the second German,
=09and if this also fails to use English. This is possible with
=09the variable LANGUAGE. For further description of this GNU
=09extension see section User influence on gettext
=09(http://www.gnu.org/manual/glibc/html_mono/libc.html#SEC137)."



Christian

[Scrollkeeper-devel] language list

[<las...@Su...>]

Hi,

Another crosspost ...

I am trying to implement a similar language list mechanism as in
gnome-libs/gnome_i18n_get_language_list(). This is about querying
LC_ALL, LC_MESSAGES and LANG in this order, in fact setlocale() does
this all for me. My problem is that although this is implemented in
gnome-libs() Linux does not seem to like language lists in these
variables. I tried to set some lists, but my setlocale() call still
returns C, although the environment variables are set to the list. I
dont know what am I doing wrong. On the other hand on Solaris setting
these variables to a language list is illegal, it can be set to one
locale only and only to one of those that are installed.

Any thoughts?

Laszlo

[Scrollkeeper-devel] Re: Migration to libxml2

[Karl E. <ke...@gm...>]

L=E1szl=F3 Kov=E1cs <las...@su...> writes:

> > (now we moved to XML and UTF-8 so this is history)
> Happy people:-) I wonder if it could be made history for Gnome too.=20

No need to "move" -- just delegate:

    Don't install SGML files but "convert" them at installation time to
    XML (sgmlnorm and s2x can do wonders).  Proposed earlier by me.
    It's still beyond me why the doc team insists on "We Want Our
    'Tools' to Work on 'pristine' SGML files".

    Don't waste your time writing hacks to process SGML files for
    display purposes.  These days SGML is for writers only (more or
    less).

--=20
work : ke...@su...                          |                   ,__o
     : http://www.suse.de/~ke/             |                 _-\_<,
home : ke...@gm...                     |                (*)/'(*)

Re: [Scrollkeeper-devel] Migration to libxml2

[<las...@su...>]

> At KDE we assumed that <book lang="ru"> induced koi-8r encoding, <book
> lang="fr"> induced iso-8859-15 encoding, etc.
> 
> (now we moved to XML and UTF-8 so this is history)
Happy people:-) I wonder if it could be made history for Gnome too. 

Laszlo

Re: [Scrollkeeper-devel] Migration to libxml2

[Eric B. <e.b...@no...>]

Le Saturday 19 May 2001 08:57, Daniel Veillard a =E9crit :
> On Fri, May 18, 2001 at 03:48:05PM -0400, Norman Walsh wrote:
> > / Dan Mueth <d-...@uc...> was heard to say:
> > | How do these deal with the lack of encoding specification for
> > | DocBook/SGML docs?  It isn't obvious to me why it is a problem for =
XML
> > | docs and libxml2 but not for SGML docs with jade/SP.
> >
> > I'm not sure.
>
>   Argh, if you don't know, who will ... Maybe we will have to ask James.

I know probably as much, or less, as Norm. Here is what I know

SP (jade, SX, etc) has defined rules about the encoding to use. These rul=
es=20
are based on the document's contents as well as the system's default=20
character set and environment variables.

The detailed rules are on:
	http://www.jclark.com/sp/charset.htm

> BTW, if automatic encoding detection is not possible, is there a way in
> DocBook to indicate the encoding if known (for example on the root elem=
ent)
> ? If this detection/advertizing requires human input, it would be great=
 to
> have to deal with it only once.

--=20
+----------------------------------------------------------------------+
| =C9ric Bischoff                              mailto:e.b...@no... =
|
+----------------------------------------------------------------------+