scrollkeeper-devel — Developer discussion list for ScrollKeeper

Re: [Scrollkeeper-devel] Index support

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

John Fleck wrote:
> 
> Hi,
> 
> I've mocked up a short DocBook document below with what I hope are
> relatively complete examples of the use of indexterm tags as an
> example to get our discussion of indexing in ScrollKeeper started.
> 
> From a functional point of view, I'd like the system to be capable of
> two things:
> 
> 1) Providing the data necessary to the help system browser to generate a
> system-wide index of all the documents registered with ScrollKeeper
> 
> 2) Providing the data necessary for the browser to generate a
> document-specific appendix for a particular document

Could you detail the appendix a bit please? I am not sure what it is
exactly. Apart from this I think Scrollkeeper should be able to extract
index from one doc and offer that two the user. We can build a
system-wide index on that as offered by Scrollkeeper or we can leave it
to the browser to do this.
 
> An optional third capability I'd like to consider is a middle ground
> that is likely implicit in 1) above, the capability to generate a
`> system-wide index for all the documentation in a given SK category.
This is simple if we store separately the index info of each doc.

> This seems reasonable. I see something along these lines, with a
> series of "terms" - the terms to be listed in the index - with an
> "instance" for each occurence of the term as an indexentry in a
> document. Each instance would then record the necessary anchor
> information. To be most useful, we should record both the id of
> the indexterm itself and the id of the enclosing sect. That would
> allow flexibility for the help browser folks.
Storing the enclosing sect also might be a good idea.

> 
> I leave the specifics of the xml data structure to the wizards in the
> group, but conceptually I'm thinking of something along these lines:
> 
> ***************************************
> 
> <indexentry term="term"> (this would be based on the primary term in
>                           an indexterm)
> 
>         <instance>
>                 <secondary>secondaryterm</secondary> (optional)
> 
>                 <doc>/pathtofile/filename.sgml</doc> (the location of
>                                                       the file)
> 
>                 <category>category</category>        (the omf category
>                                                       of the doc)
> 
>                 <sectid>sectid</sectid>              (the id of the
>                                                       section in which
>                                                       the indexterm is
>                                                       located)
> 
>                 <indextermid>idid</indextermid>      (the id of the
>                                                       indexterm
>                                                       itself)
> 
>                 <indextermrangeend>anotherid</indextermrangeend> (the
>                                                       id for the end
>                                                       of the indexterm
>                                                       range if used)
> 
>                 <seealso>otherterm</seealso>         (a pointer to
>                                                       another term - optional)
>         </instance>
> 
>         <instance>
>             ............. another instance .............
>             ............. possibly in the same doc .....
>             ............. or a different one ...........
>         </instance>
> 
> </indexentry>

This sounds resonable with the addition that we are looking into the
implementation of a doc id that would be the same for a doc and all its
translations, so the actual information about the doc stored here might
be a bit different.

> 
> *****************************************
> 
> Some questions to consider:
> 
> - how should we handle locale? I expect we should have a separate xml
> index file for each locale, based on the language code in the omf.
Yes. This should be pretty similar to the TOC implementation. Right now
Scrollkeeper assigns a unique id to every installed doc and the TOC of
the doc is stored in the TOC subdirectory of the scrollkeeper database
directory in a file that has the ID as its name.
 
> - DocBook indexterm also supports attributes "zone," "significance",
> "scope" and "pagenum". How should we treat those?
I have no idea, this is up to people who know more about SGML in
general.

Finally dont be shy to cut out everything from your mails quoted texts
that is not related as we already managed to grow emails to unbearable
sizes at previous design related discussions.

Laszlo

Re: [Scrollkeeper-devel] omf question

[Paul J. <pj...@me...>]

let me take a crack at answering your questions and other omf folks please
correct me.
paul

On Thu, 15 Mar 2001, David Merrill wrote:

+I am intentionally crossposting this because IMO this needs to be a
+joint conversation. Sorry to those (hopefully) few people who are on
+both lists.
+
+Greg Ferguson wrote a perl script to convert docbook sgml metadata
+into omf format. It is called, logically enough, db2omf.
+I will have some questions about your example omf file and how it
+relates to ours.
+
+Here is an annoted version of my first test omf file:
+
+
+<?xml version="1.0" standalone="no"?>
+
+# your file doesn't include the dtd declaration
+<!DOCTYPE omf SYSTEM "OMF.dtd">
+<omf xmlns="http://metalab.unc.edu/osrt/omf/" created="20010315" agent="db2omf">
+
+  # I have no idea what the created means. :-)
+  # I wrote to Ferg and asked but it's late and he's not at work.
this defines what dtd was used to create this metadata including the
version number, the official location for information on the dtd, the
agent that created this metadata, etc.

+  <resource created="20010315">
+    <title created="20010315">Linux Assembly HOWTO</title>
+    <date created="20010315">20010215</date>
+    <creator created="20010315">
+      <person created="20010315">
+        <firstName created="20010315">
+          Konstantin
+        </firstName>
+        <lastName created="20010315">
+          Boldyshev
+        </lastName>
+        <email created="20010315">
+          ko...@li...
+        </email>
+      </person>
+    </creator>
+
+    # You don't have version information in your example.
+    # I dont' know if ours is right yet, either. This is a pre-alpha
+    # (non) release.
+    <versionGroup created="20010315">
+      <version created="20010315">
+        <id created="20010315">
officially you would not be required to enter a version number as it is
optional information see http://www.ibiblio.org/osrt/omf/omf_elements
+          # I suspect this is wrong. Too much info. But it could exist
+	  # in the original docbook, too. Haven't checked that yet.
+	  # This is why I want to get started doing omf early. There
+	  # will be wrinkles to work out. We may have to update all
+	  # our documents' source.
+          0.6c15 Feb 2001konst
+        </id>
+        <date created="20010315">
+          20010215
+        </date>
+      </version>
+    </versionGroup>
+
you are right we don't support a sub-label of category. how would you
define that?
+    # Note that we do not have categories. We need your advice.
+    # Have you established a system of categorization? I see the
+    # <subject><category>System|Other</category></subject>, but I am
+    # wondering what the available values are. Can there be multiple
+    # categories?
not a bad idea
+    # We are pulling keywords from the title of the document.
+    # We will have to come up with a better approach.
+    <keywords created="20010315">assembly</keywords>
+    <keywords created="20010315">howto</keywords>
+    <keywords created="20010315">linux</keywords>
+
+    <description created="20010315">
+       This is the Linux Assembly HOWTO, version &version;. This
+       document describes how to program in assembly language using
+       free programming tools, focusing on development for or from
+       the Linux Operating System, mostly on IA-32 (i386) platform.
+       Included material may or may not be applicable to other
+       hardware and/or software platforms.
+    </description>
+
+    # Are you working from the list established in the latest omf
+    # specification? If so, good. I also just asked for a new value,
+    # "Quick Reference" since the LDP is going to start working on a
+    # series of them. Someday.
would this be a new TYPE? again see
http://www.ibiblio.org/osrt/omf/omf_elements
+    <type created="20010315">HOWTO</type>
+
+    <format created="20010315" dtd="DocBook" mime="text/sgml" />
+
+    # Ours includes "file://" and yours does not. Which is correct?
+    <identifier created="20010315" url="file://home/david/ldp/cvs/LDP/howto/docbook/Assembly-HOWTO.sgml" />
+
+    # Are you using relation, and if so, how? I don't see it in your
+    # example.
+    <relation created="20010315" url="" />
+
+    # I see Ferg isn't done with this yet, but I did check rfc
+    # 1766, and your "C" value should be an ISO language code.
+    <language created="20010315" code="EN" name="English" src="" />
+
+  </resource>
+</omf>
+
+

-- 
==========================================================================
                             Paul Jones
                    "Gort! Klaatu barada nikto!"
http://www.ibiblio.org/pjones/ at the Site Formerly Known As MetaLab.unc.edu
  pj...@ib...   voice: (919) 962-7600     fax: (919) 962-8071
===========================================================================

Re: [Scrollkeeper-devel] Index support

[John F. <jf...@sw...>]

Hi,

I've mocked up a short DocBook document below with what I hope are
relatively complete examples of the use of indexterm tags as an
example to get our discussion of indexing in ScrollKeeper started.

From a functional point of view, I'd like the system to be capable of
two things:

1) Providing the data necessary to the help system browser to generate a
system-wide index of all the documents registered with ScrollKeeper

2) Providing the data necessary for the browser to generate a
document-specific appendix for a particular document

An optional third capability I'd like to consider is a middle ground
that is likely implicit in 1) above, the capability to generate a
system-wide index for all the documentation in a given SK category.

On Tue, Mar 13, 2001 at 05:21:05PM +0000, Laszlo Kovacs wrote:
>
> Anyway I think the way it should be done is that we take the SGML file
> and extract the index info from it into a very simple xml file. Ideally
> this should contain only the index strings and the "anchor" in the text
> that is associated with them.

This seems reasonable. I see something along these lines, with a
series of "terms" - the terms to be listed in the index - with an
"instance" for each occurence of the term as an indexentry in a
document. Each instance would then record the necessary anchor
information. To be most useful, we should record both the id of
the indexterm itself and the id of the enclosing sect. That would
allow flexibility for the help browser folks.

I leave the specifics of the xml data structure to the wizards in the
group, but conceptually I'm thinking of something along these lines:

***************************************

<indexentry term="term"> (this would be based on the primary term in
			  an indexterm)

	<instance>
		<secondary>secondaryterm</secondary> (optional)

		<doc>/pathtofile/filename.sgml</doc> (the location of
						      the file)

		<category>category</category>	     (the omf category
						      of the doc)

		<sectid>sectid</sectid>              (the id of the
						      section in which
						      the indexterm is
						      located)

		<indextermid>idid</indextermid>      (the id of the
						      indexterm
						      itself)
	
		<indextermrangeend>anotherid</indextermrangeend> (the
						      id for the end
						      of the indexterm
						      range if used)

		<seealso>otherterm</seealso>         (a pointer to
						      another term - optional)
	</instance>

	<instance>
	    ............. another instance .............
            ............. possibly in the same doc .....
	    ............. or a different one ...........
	</instance>

</indexentry> 

*****************************************

Some questions to consider:

- how should we handle locale? I expect we should have a separate xml
index file for each locale, based on the language code in the omf.

- DocBook indexterm also supports attributes "zone," "significance",
"scope" and "pagenum". How should we treat those?

A sample doc:
***********************************************************
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN" [
]>
<article id="index">

  <sect1 id="sect1-01">
    <title>Indexterm</title>
    <para>
      <indexterm id="idx-id1">
	<primary>indexterm</primary>
      </indexterm>
      This paragraph contains some content that will be indexed using an
      ordinary single-point indexterm.</para>
  </sect1>

  <sect1 id="sect1-02">
    <title>Range</title>
    <para>
      <indexterm id="idx-id2" class="startofrange">
	<primary>indexterm</primary>
	<secondary>range</secondary>
      </indexterm>
      This paragraph contains some content that will be indexed using an
      indexterm range.
      <indexterm startref="idx-id2" class="endofrange">
	
    </para>
  </sect1>


  <sect1 id="sect1-03">
    <title>Seealso</title>
    <para>
      <indexterm id="idx-id3">
	<primary>seealso</primary>
	<seealso>indexterm</seealso>
      </indexterm>
      This paragraph contains content regarding the seealso tag, with a seealso
      reference to indexterm in the index.
    </para>

    <sect2 id="sect2-01">
      <title>Indexterm in nested sect2</title>
      <para>
      <indexterm id="idx-id4">
	<primary>nested</primary>
      </indexterm>
	Here is some text in a sect2 that will be indexed.
      </para>
    </sect2>

  </sect1>

</article>
*****************************************************

Cheers,
-- 
John Fleck
jf...@sw... (h)
jf...@ab... (w)
http://www.abqjournal.com/scitech/

[Scrollkeeper-devel] omf question

[David M. <da...@lu...>]

I am intentionally crossposting this because IMO this needs to be a
joint conversation. Sorry to those (hopefully) few people who are on
both lists.

Greg Ferguson wrote a perl script to convert docbook sgml metadata
into omf format. It is called, logically enough, db2omf.
I will have some questions about your example omf file and how it
relates to ours.

Here is an annoted version of my first test omf file:


<?xml version="1.0" standalone="no"?>

# your file doesn't include the dtd declaration
<!DOCTYPE omf SYSTEM "OMF.dtd">
<omf xmlns="http://metalab.unc.edu/osrt/omf/" created="20010315" agent="db2omf">

  # I have no idea what the created means. :-)
  # I wrote to Ferg and asked but it's late and he's not at work.
  <resource created="20010315">
    <title created="20010315">Linux Assembly HOWTO</title>
    <date created="20010315">20010215</date>
    <creator created="20010315">
      <person created="20010315">
        <firstName created="20010315">
          Konstantin
        </firstName>
        <lastName created="20010315">
          Boldyshev
        </lastName>
        <email created="20010315">
          ko...@li...
        </email>
      </person>
    </creator>

    # You don't have version information in your example.
    # I dont' know if ours is right yet, either. This is a pre-alpha
    # (non) release.
    <versionGroup created="20010315">
      <version created="20010315">
        <id created="20010315">

          # I suspect this is wrong. Too much info. But it could exist
	  # in the original docbook, too. Haven't checked that yet.
	  # This is why I want to get started doing omf early. There
	  # will be wrinkles to work out. We may have to update all
	  # our documents' source.
          0.6c15 Feb 2001konst
        </id>
        <date created="20010315">
          20010215
        </date>
      </version>
    </versionGroup>

    # Note that we do not have categories. We need your advice.
    # Have you established a system of categorization? I see the
    # <subject><category>System|Other</category></subject>, but I am
    # wondering what the available values are. Can there be multiple
    # categories?
    
    # We are pulling keywords from the title of the document.
    # We will have to come up with a better approach.
    <keywords created="20010315">assembly</keywords>
    <keywords created="20010315">howto</keywords>
    <keywords created="20010315">linux</keywords>

    <description created="20010315">
       This is the Linux Assembly HOWTO, version &version;. This
       document describes how to program in assembly language using
       free programming tools, focusing on development for or from
       the Linux Operating System, mostly on IA-32 (i386) platform.
       Included material may or may not be applicable to other
       hardware and/or software platforms. 
    </description>

    # Are you working from the list established in the latest omf
    # specification? If so, good. I also just asked for a new value,
    # "Quick Reference" since the LDP is going to start working on a
    # series of them. Someday.
    
    <type created="20010315">HOWTO</type>
    
    <format created="20010315" dtd="DocBook" mime="text/sgml" />

    # Ours includes "file://" and yours does not. Which is correct?
    <identifier created="20010315" url="file://home/david/ldp/cvs/LDP/howto/docbook/Assembly-HOWTO.sgml" />

    # Are you using relation, and if so, how? I don't see it in your
    # example.
    <relation created="20010315" url="" />

    # I see Ferg isn't done with this yet, but I did check rfc
    # 1766, and your "C" value should be an ISO language code.
    <language created="20010315" code="EN" name="English" src="" />

  </resource>
</omf>

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                   da...@lu...
Collection Editor & Coordinator            http://www.linuxdoc.org
                                       Finger me for my public key

"Now this is a totally brain damaged algorithm.  Gag me with a smurfette."
		-- P. Buhr, Computer Science 354

Re: [Scrollkeeper-devel] Index support

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

I obviously forgot some of the stuff I wanted to mention. If we want to
implement Search later on as part of Scrollkeeper then the index support
should be done keeping in mind that it should be easily searchable later
on. If we leave the search to the browser then we dont need this.

Laszlo

> 
> Hi,
> 
> We've been talking for a while about adding index support to
> Scrollkeeper. It looks like we have the people to work on it now, Mary
> Dwyer (from Sun), John Fleck and Sasha most of the time. mary would
> probably do the development work.
> 
> I frame up my idea about how should it be done and we can discuss it.
> 
> I dont know much about index tags in DocBook/SGML so I am not sure how
> we implement this. I think there are two ways of indexing, one that just
> defines the index term and an "anchor" to where it is discussed (or
> maybe more anchors?) and the other holds the index definition itself.
> 
> Anyway I think the way it should be done is that we take the SGML file
> and extract the index info from it into a very simple xml file. Ideally
> this should contain only the index strings and the "anchor" in the text
> that is associated with them. I dont know if the SGML index tags support
> this aproach.
> 
> On the technical side I think we should use a SAX interface rather then
> a DOM tree as very little info from the SGML docs is actually used.
> 
> The index extractor should be a new binary or part of the Scrollkeeper
> library if we manage to turn SK to a library.
> 
> This is a very short description, but I think it contains the main
> issues.
> 
> What do you think about it?
> 
> Laszlo
>

[Scrollkeeper-devel] Index support

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

Hi,

We've been talking for a while about adding index support to
Scrollkeeper. It looks like we have the people to work on it now, Mary
Dwyer (from Sun), John Fleck and Sasha most of the time. mary would
probably do the development work.

I frame up my idea about how should it be done and we can discuss it.

I dont know much about index tags in DocBook/SGML so I am not sure how
we implement this. I think there are two ways of indexing, one that just
defines the index term and an "anchor" to where it is discussed (or
maybe more anchors?) and the other holds the index definition itself.

Anyway I think the way it should be done is that we take the SGML file
and extract the index info from it into a very simple xml file. Ideally
this should contain only the index strings and the "anchor" in the text
that is associated with them. I dont know if the SGML index tags support
this aproach.

On the technical side I think we should use a SAX interface rather then
a DOM tree as very little info from the SGML docs is actually used. 

The index extractor should be a new binary or part of the Scrollkeeper
library if we manage to turn SK to a library.

This is a very short description, but I think it contains the main
issues.

What do you think about it?

Laszlo

[Scrollkeeper-devel] scrollkeeper-example1 released

[Dan M. <da...@ea...>]

Finally, after a very long wait, I finally put together some information
on how to make a package play nicely with ScrollKeeper.  Instead of
writing a long manual on ScrollKeeper, which I still intend to do, I
decided it would be more valuable to set up an example application with
some comments, documentation, and template files which people can copy
into their own packages.

By copying a couple makefiles out of this package along with examples of
OMF files, you will be mostly done setting up your package.  There is also
information on how to set up your configure.in and spec file (for RPM
users).  And don't forget to read the short document which installs with
it, which has some additional info to supplement the comments in the
various build files.

You can get the release from here:

http://sourceforge.net/projects/scrollkeeper/

Or get it from SourceForge CVS in the 'scrollkeeper_examples' module using
the instructions here:

http://sourceforge.net/cvs/?group_id=11543

This is not a final release, as it could still use some fixing
up.  However, it should definitely be sufficient to set up a package to
install and register DocBook/SGML docs with scrollkeeper.

Coming in the next release:
  A nice template makefile and example on installing HTML docs, and maybe
  even PS and PDF docs too.

Feedback and patches are welcome.

Dan

Warning: ScrollKeeper is still beta software and could explode or morph
into something evil at any time.

Re: [Scrollkeeper-devel] db2omf

[David M. <da...@lu...>]

On Thu, Mar 08, 2001 at 02:33:35PM -0800, Dan Mueth wrote:
> 
> On Thu, 8 Mar 2001, David Merrill wrote:
> 
> > On Thu, Mar 08, 2001 at 01:22:06PM -0800, Dan Mueth wrote:
> > > 
> > > 
> > > On Thu, 8 Mar 2001, David Merrill wrote:
> > > 
> > > > Has anyone done any work toward creating omf from docbook sgml/xml
> > > > sources? I want to do some testing of LDP packaging for use with
> > > > scrollkeeper. I would like to not have to maintain omf separately from
> > > > our docbook if that is possible.
> > > > 
> > > > I'd be happy to help expand the sk documentation as I go along.
> > > > 
> > > > Any other tips gratefully accepted!
> > > 
> > > Dave,
> > > 
> > > Nobody has started work on this yet and this would be a valuable addition
> > > to scrollkeeper.  This is especially true since most documentation is in
> > > DocBook.  There are two problems that come to mind:
> > > 1) DocBook does not yet support all of the OMF tags
> > > 2) The OMF DTD will be changing somewhat, since it is not in
> > > complete agreement with the OMF specification and because we are
> > > discussing adding a couple new elements or attributes.
> > > 
> > > However, both of these are very solvable problems, and really need to be
> > > solved.  Norman Walsh has agreed to help get the necessary tags into
> > > DocBook.  And fixing the DTD is a matter of somebody (Gregory Leblanc I
> > > think is the maintainer of the DTD) putting in some time and resolving the
> > > outstanding issues on the ldp-meta mailing list.
> > > 
> > > If you'd like to get started anyway, realizing that things will be in a
> > > state of flux for a little while, that would be great.  In the short term,
> > > people could run it manually to generate partially completed OMF file
> > > templates and then manually fill in the missing bits.  In the longer term,
> > > we can have scrollkeeper-preinstall run db2omf on DocBook files so that
> > > the OMF files are not created until build time.
> > > 
> > > BTW: I wasn't sure what you meant by "testing of LDP packaging", but I
> > > have almost finished a new example package which illustrates one of the
> > > simpler ways to set up a package to use scrollkeeper and handle DocBook
> > > properly, and it provides templates and some documentation to make things
> > > easier.  I'm hoping to release it today.
> > 
> > My immediate goal is to establish docbook guidelines for our authors,
> > so that their docbook is omf-ready, and to position us to fully
> > support scrollkeeper. I keep the LDP up to date with what sk is doing,
> > or at least as up to date as *I* am.
> 
> This is good to hear.
> 
> > An LDP volunteer is going to work on a db2omf script, and I will send
> > it to you when it is ready. I asked him to license GPL so you can use
> > it without license issues.
> 
> Thanks.  We have licensed scrollkeeper under the LGPL because it will
> become a proper library.  Since it makes sense to have db2omf be a part of
> scrollkeeper so that the OMF is generated from the DocBook at install
> time, we would need to license it under the LGPL.  Would this be okay with
> you?

Sure.

> > If scrollkeeper is going to generate omf from db directly, then does
> > that mean the LDP won't need to generate omf for you? That was the
> > basis of my thinking, and if that goes away then we don't really need
> > to do anything extra. But we'll still work on the db2omf script.
> 
> I think it will be a while until we get to this step.  First we have to
> finalize the OMF DTD and then we have to get it accepted into DocBook and
> wait for a DocBook release to incorporate it.  I suspect the DocBook
> process will take a long time.
> 
> I'm hoping to have the OMF DTD figured out within the next month or two
> and then start the DocBook process.

For the time being, we will create the script for generating omf from
docbook as it stands now - db3.1 or db4.x sgml or xml. When docbook
gets updated to support omf natively, we can deal with it. When sk
goes beta, I want to have the LDP documentation included. We've done a
lot of work, as have the other documentation projects, to create the
content, but the delivery right now sucks. We hope sk will change
that, and I personally consider it very important that you succeed.
Good luck!

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                   da...@lu...
Collection Editor & Coordinator            http://www.linuxdoc.org
                                       Finger me for my public key

Postmen never die, they just lose their zip.

Re: [Scrollkeeper-devel] db2omf

[Dan M. <da...@ea...>]

On Thu, 8 Mar 2001, David Merrill wrote:

> On Thu, Mar 08, 2001 at 01:22:06PM -0800, Dan Mueth wrote:
> > 
> > 
> > On Thu, 8 Mar 2001, David Merrill wrote:
> > 
> > > Has anyone done any work toward creating omf from docbook sgml/xml
> > > sources? I want to do some testing of LDP packaging for use with
> > > scrollkeeper. I would like to not have to maintain omf separately from
> > > our docbook if that is possible.
> > > 
> > > I'd be happy to help expand the sk documentation as I go along.
> > > 
> > > Any other tips gratefully accepted!
> > 
> > Dave,
> > 
> > Nobody has started work on this yet and this would be a valuable addition
> > to scrollkeeper.  This is especially true since most documentation is in
> > DocBook.  There are two problems that come to mind:
> > 1) DocBook does not yet support all of the OMF tags
> > 2) The OMF DTD will be changing somewhat, since it is not in
> > complete agreement with the OMF specification and because we are
> > discussing adding a couple new elements or attributes.
> > 
> > However, both of these are very solvable problems, and really need to be
> > solved.  Norman Walsh has agreed to help get the necessary tags into
> > DocBook.  And fixing the DTD is a matter of somebody (Gregory Leblanc I
> > think is the maintainer of the DTD) putting in some time and resolving the
> > outstanding issues on the ldp-meta mailing list.
> > 
> > If you'd like to get started anyway, realizing that things will be in a
> > state of flux for a little while, that would be great.  In the short term,
> > people could run it manually to generate partially completed OMF file
> > templates and then manually fill in the missing bits.  In the longer term,
> > we can have scrollkeeper-preinstall run db2omf on DocBook files so that
> > the OMF files are not created until build time.
> > 
> > BTW: I wasn't sure what you meant by "testing of LDP packaging", but I
> > have almost finished a new example package which illustrates one of the
> > simpler ways to set up a package to use scrollkeeper and handle DocBook
> > properly, and it provides templates and some documentation to make things
> > easier.  I'm hoping to release it today.
> 
> My immediate goal is to establish docbook guidelines for our authors,
> so that their docbook is omf-ready, and to position us to fully
> support scrollkeeper. I keep the LDP up to date with what sk is doing,
> or at least as up to date as *I* am.

This is good to hear.

> An LDP volunteer is going to work on a db2omf script, and I will send
> it to you when it is ready. I asked him to license GPL so you can use
> it without license issues.

Thanks.  We have licensed scrollkeeper under the LGPL because it will
become a proper library.  Since it makes sense to have db2omf be a part of
scrollkeeper so that the OMF is generated from the DocBook at install
time, we would need to license it under the LGPL.  Would this be okay with
you?

> If scrollkeeper is going to generate omf from db directly, then does
> that mean the LDP won't need to generate omf for you? That was the
> basis of my thinking, and if that goes away then we don't really need
> to do anything extra. But we'll still work on the db2omf script.

I think it will be a while until we get to this step.  First we have to
finalize the OMF DTD and then we have to get it accepted into DocBook and
wait for a DocBook release to incorporate it.  I suspect the DocBook
process will take a long time.

I'm hoping to have the OMF DTD figured out within the next month or two
and then start the DocBook process.

Dan

Re: [Scrollkeeper-devel] db2omf

[David M. <da...@lu...>]

On Thu, Mar 08, 2001 at 01:22:06PM -0800, Dan Mueth wrote:
> 
> 
> On Thu, 8 Mar 2001, David Merrill wrote:
> 
> > Has anyone done any work toward creating omf from docbook sgml/xml
> > sources? I want to do some testing of LDP packaging for use with
> > scrollkeeper. I would like to not have to maintain omf separately from
> > our docbook if that is possible.
> > 
> > I'd be happy to help expand the sk documentation as I go along.
> > 
> > Any other tips gratefully accepted!
> 
> Dave,
> 
> Nobody has started work on this yet and this would be a valuable addition
> to scrollkeeper.  This is especially true since most documentation is in
> DocBook.  There are two problems that come to mind:
> 1) DocBook does not yet support all of the OMF tags
> 2) The OMF DTD will be changing somewhat, since it is not in
> complete agreement with the OMF specification and because we are
> discussing adding a couple new elements or attributes.
> 
> However, both of these are very solvable problems, and really need to be
> solved.  Norman Walsh has agreed to help get the necessary tags into
> DocBook.  And fixing the DTD is a matter of somebody (Gregory Leblanc I
> think is the maintainer of the DTD) putting in some time and resolving the
> outstanding issues on the ldp-meta mailing list.
> 
> If you'd like to get started anyway, realizing that things will be in a
> state of flux for a little while, that would be great.  In the short term,
> people could run it manually to generate partially completed OMF file
> templates and then manually fill in the missing bits.  In the longer term,
> we can have scrollkeeper-preinstall run db2omf on DocBook files so that
> the OMF files are not created until build time.
> 
> BTW: I wasn't sure what you meant by "testing of LDP packaging", but I
> have almost finished a new example package which illustrates one of the
> simpler ways to set up a package to use scrollkeeper and handle DocBook
> properly, and it provides templates and some documentation to make things
> easier.  I'm hoping to release it today.

My immediate goal is to establish docbook guidelines for our authors,
so that their docbook is omf-ready, and to position us to fully
support scrollkeeper. I keep the LDP up to date with what sk is doing,
or at least as up to date as *I* am.

An LDP volunteer is going to work on a db2omf script, and I will send
it to you when it is ready. I asked him to license GPL so you can use
it without license issues.

If scrollkeeper is going to generate omf from db directly, then does
that mean the LDP won't need to generate omf for you? That was the
basis of my thinking, and if that goes away then we don't really need
to do anything extra. But we'll still work on the db2omf script.

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                   da...@lu...
Collection Editor & Coordinator            http://www.linuxdoc.org
                                       Finger me for my public key

gurmlish, n.:
	The red warning flag at the top of a club sandwich which
	prevents the person from biting into it and puncturing the roof
	of his mouth.
		-- Rich Hall, "Sniglets"

Re: [Scrollkeeper-devel] db2omf

[Dan M. <da...@ea...>]

On Thu, 8 Mar 2001, David Merrill wrote:

> Has anyone done any work toward creating omf from docbook sgml/xml
> sources? I want to do some testing of LDP packaging for use with
> scrollkeeper. I would like to not have to maintain omf separately from
> our docbook if that is possible.
> 
> I'd be happy to help expand the sk documentation as I go along.
> 
> Any other tips gratefully accepted!

Dave,

Nobody has started work on this yet and this would be a valuable addition
to scrollkeeper.  This is especially true since most documentation is in
DocBook.  There are two problems that come to mind:
1) DocBook does not yet support all of the OMF tags
2) The OMF DTD will be changing somewhat, since it is not in
complete agreement with the OMF specification and because we are
discussing adding a couple new elements or attributes.

However, both of these are very solvable problems, and really need to be
solved.  Norman Walsh has agreed to help get the necessary tags into
DocBook.  And fixing the DTD is a matter of somebody (Gregory Leblanc I
think is the maintainer of the DTD) putting in some time and resolving the
outstanding issues on the ldp-meta mailing list.

If you'd like to get started anyway, realizing that things will be in a
state of flux for a little while, that would be great.  In the short term,
people could run it manually to generate partially completed OMF file
templates and then manually fill in the missing bits.  In the longer term,
we can have scrollkeeper-preinstall run db2omf on DocBook files so that
the OMF files are not created until build time.

BTW: I wasn't sure what you meant by "testing of LDP packaging", but I
have almost finished a new example package which illustrates one of the
simpler ways to set up a package to use scrollkeeper and handle DocBook
properly, and it provides templates and some documentation to make things
easier.  I'm hoping to release it today.

Dan

[Scrollkeeper-devel] db2omf

[David M. <da...@lu...>]

Has anyone done any work toward creating omf from docbook sgml/xml
sources? I want to do some testing of LDP packaging for use with
scrollkeeper. I would like to not have to maintain omf separately from
our docbook if that is possible.

I'd be happy to help expand the sk documentation as I go along.

Any other tips gratefully accepted!

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                   da...@lu...
Collection Editor & Coordinator            http://www.linuxdoc.org
                                       Finger me for my public key

FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #13
A:	Doc, Happy, Bashful, Dopey, Sneezy, Sleepy, & Grumpy
Q:	Who were the Democratic presidential candidates?

[Scrollkeeper-devel] scrollkeeper: configure.in

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

AFAIKS, there's no need to check for C++; at least, it builds without a
C++ compiler installed :)

2001-03-06  Karl Eichwalder  <ke...@su...>

	* configure.in: Don't check for a C++ compiler.

--- scrollkeeper-0.1.4/configure.in.~1~	Mon Mar  5 09:38:21 2001
+++ scrollkeeper-0.1.4/configure.in	Tue Mar  6 10:22:11 2001
@@ -6,7 +6,7 @@
 AC_ISC_POSIX
 
 dnl Checks for programs.
-AC_PROG_CXX
+dnl AC_PROG_CXX
 AC_PROG_AWK
 AC_PROG_CC
 AC_PROG_CPP


-- 
Linux Frechet 2.2.18 #1 Fri Jan 19 22:10:35 GMT 2001 i686 unknown
  4:44pm  up  8:23,  6 users,  load average: 0.22, 0.17, 0.08
                                             work    :      ke...@su...
Karl Eichwalder                              home    : ke...@gm...

[Scrollkeeper-devel] ScrollKeeper 0.1.4 Released

[Dan M. <da...@ea...>]

Hi folks,

I just released ScrollKeeper 0.1.4.  You can get it here:
http://sourceforge.net/project/showfiles.php?group_id=11543&release_id=26145

This release fixes a handful of annoying quirks from 0.1.3.

Dan

------

Release Notes:

This is primarily a bug fix and cleanup release.  The build system and
spec file were cleaned up and made more robust.  A couple changes to the
scripts were made to make things more robust.  Suppressed some warnings
which often occured during scrollkeeper-update, ie. when RPM installations
were done.  It now creates HTML docs at make dist, and installs them
properly.

Re: [Scrollkeeper-devel] -//GNOME//DTD DocBook PNG Variant V1.1//EN where?

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

Paul Jones <pj...@me...> writes:

> sorry not to have gotten youe message to ldp-meta. it's a small
> list. the web interface is an attempt to make it very easy to use, but
> you could and can use any of the standard email subscribe commands as
> well.

I'm not good in web browsing and such things (and I've always the
feeling these web interface are lying...) ;)

Thanks for your answer!  The good news is: I'm already subscribed.  And
thanks for taking care about the very important project!

All the best,
Karl

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

Re: [Scrollkeeper-devel] -//GNOME//DTD DocBook PNG Variant V1.1//EN where?

[Paul J. <pj...@me...>]

sorry not to have gotten youe message to ldp-meta. it's a small list. the
web interface is an attempt to make it very easy to use, but you could and
can use any of the standard email subscribe commands as well.
for example:
send mail to lis...@fr... (or majordomo or other famous
listserver names) with a single line of:
subscribe ldp-meta

On 4 Mar 2001, Karl Eichwalder wrote:

+Dan Mueth <da...@ea...> writes:
+
+> I haven't seen this information.  I would recommend joining the ldp-meta
+> mailing list and asking there:
+>
+> http://franklin.oit.unc.edu/cgi-bin/lyris.pl?enter=ldp-meta
+
+Yes, I tried.  Not sure whether my request was accepted by this great
+web interface...  If people aren't able to provide a standard subscribe
+method (preferable by mail) I'll not care any longer.
+
+Thanks Dan for all your help; I know it's not your fault!
+
+

==========================================================================
                             Paul Jones
                    "Gort! Klaatu barada nikto!"
http://www.ibiblio.org/pjones/ at the Site Formerly Known As MetaLab.unc.edu
  pj...@ib...   voice: (919) 962-7600     fax: (919) 962-8071
===========================================================================

Re: [Scrollkeeper-devel] -//GNOME//DTD DocBook PNG Variant V1.1//EN where?

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

Dan Mueth <da...@ea...> writes:

> I haven't seen this information.  I would recommend joining the ldp-meta
> mailing list and asking there:
> 
> http://franklin.oit.unc.edu/cgi-bin/lyris.pl?enter=ldp-meta

Yes, I tried.  Not sure whether my request was accepted by this great
web interface...  If people aren't able to provide a standard subscribe
method (preferable by mail) I'll not care any longer.

Thanks Dan for all your help; I know it's not your fault!

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

Re: [Scrollkeeper-devel] -//GNOME//DTD DocBook PNG Variant V1.1//EN where?

[Dan M. <da...@ea...>]

On 4 Mar 2001, Karl Eichwalder wrote:

> Do you have some hints how to checkout the OMF CVS module?  I tried:
> 
>     CVSROOT=:pserver:cv...@ww...:/osrt/omf/cvsroot
> 
> and
> 
>     CVSROOT=:pserver:ano...@ww...:/osrt/omf/cvsroot
> 
> but it doesn't let me in.  Do I need a special password?  The web page
> at http://www.ibiblio.org/osrt/omf/ only says:
> 
> OMF News 
>           XML DTD now in CVS on ibiblio
>           A CVS tree has been set up on ibiblio to handle version
>           management of the OMF XML DTD. Point your CVS clients to
>           www.ibiblio.org/osrt/omf/cvsroot or check out the CVS web
>           interface.
> 
> Yes, I found the OMF.DTD; nevertheless I'd like to ckeckout all the omf
> related files...

I haven't seen this information.  I would recommend joining the ldp-meta
mailing list and asking there:

http://franklin.oit.unc.edu/cgi-bin/lyris.pl?enter=ldp-meta

Dan

Re: [Scrollkeeper-devel] -//GNOME//DTD DocBook PNG Variant V1.1//EN where?

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

Dan Mueth <da...@ea...> writes:

> Sorry about this Karl.  You can get the DTD and some other goodies in
> gnome-doc-tools at:
> http://people.redhat.com/dcm/software.html

Thanks for the pointer.  gnome-doc-tools-1.0.tar.gz will need the patch,
too posted earlier this day (s/1.0/1.1).  All in all this tools package
isn't that usefull "foreign" distributions ;)

> I'm working on things a bit tonight and I hope to fix the build for
> the docs so they build the HTML on make dist.  I think I may also yank
> out the need for the modified DTD since we only really needed this for
> screenshots and Scrollkeeper doesn't have a GUI to take any
> screenshots of.

Sounds good - thanks!

Do you have some hints how to checkout the OMF CVS module?  I tried:

    CVSROOT=:pserver:cv...@ww...:/osrt/omf/cvsroot

and

    CVSROOT=:pserver:ano...@ww...:/osrt/omf/cvsroot

but it doesn't let me in.  Do I need a special password?  The web page
at http://www.ibiblio.org/osrt/omf/ only says:

OMF News 
          XML DTD now in CVS on ibiblio
          A CVS tree has been set up on ibiblio to handle version
          management of the OMF XML DTD. Point your CVS clients to
          www.ibiblio.org/osrt/omf/cvsroot or check out the CVS web
          interface.

Yes, I found the OMF.DTD; nevertheless I'd like to ckeckout all the omf
related files...

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

Re: [Scrollkeeper-devel] Distributed tar.gz Archive File

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

Karl Eichwalder <ke...@gm...> writes:

> In addition to the .sgml files please distribute prebuilt .html files as
> well.

Oops, in this case it has to be the other way around.  Please, don't
distribute documentation that much unfinished... ;)

Or change this intro a little bit:

   NOTE: This document, like ScrollKeeper itself, is a work in
   progress.

Thanks.

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

Re: [Scrollkeeper-devel] -//GNOME//DTD DocBook PNG Variant V1.1//EN where?

[Dan M. <da...@ea...>]

Sorry about this Karl.  You can get the DTD and some other goodies in
gnome-doc-tools at:
http://people.redhat.com/dcm/software.html

I'm working on things a bit tonight and I hope to fix the build for the
docs so they build the HTML on make dist.  I think I may also yank out the
need for the modified DTD since we only really needed this for screenshots
and Scrollkeeper doesn't have a GUI to take any screenshots of.

Dan

On 4 Mar 2001, Karl Eichwalder wrote:

> Where may I find -//GNOME//DTD DocBook PNG Variant V1.1//EN, please
> (I'm looking for the home site of this DTD)?
> 
> 

[Scrollkeeper-devel] Re: -//GNOME//DTD DocBook PNG Variant V1.1//EN where?

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

Karl Eichwalder <ke...@gm...> writes:

> Where may I find -//GNOME//DTD DocBook PNG Variant V1.1//EN, please
> (I'm looking for the home site of this DTD)?

Found it and applied this patch:

Index: png-support-3.1.dtd
===================================================================
RCS file: /cvs/gnome/gnome-docu/gdp/gnome-doc-tools/png-support-3.1.dtd,v
retrieving revision 1.1
diff -u -u -r1.1 png-support-3.1.dtd
--- png-support-3.1.dtd	2000/08/08 20:39:54	1.1
+++ png-support-3.1.dtd	2001/03/04 08:07:50
@@ -21,11 +21,11 @@
 <!--
     This DTD should be referenced in your documentation as:
 
-      <!DOCTYPE Article PUBLIC "-//GNOME//DTD DocBook PNG Variant V1.0//EN">
+      <!DOCTYPE Article PUBLIC "-//GNOME//DTD DocBook PNG Variant V1.1//EN">
 
         or 
 
-      <!DOCTYPE Book PUBLIC "-//GNOME//DTD DocBook PNG Variant V1.0//EN">
+      <!DOCTYPE Book PUBLIC "-//GNOME//DTD DocBook PNG Variant V1.1//EN">
 
     and remember to update your catalog to reference this file.
 -->
@@ -45,4 +45,4 @@
 <!ENTITY % DocBookDTD       PUBLIC
 "-//OASIS//DTD DocBook V3.1//EN"                                      >
 
-%DocBookDTD;
\ No newline at end of file
+%DocBookDTD;


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

[Scrollkeeper-devel] -//GNOME//DTD DocBook PNG Variant V1.1//EN where?

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

Where may I find -//GNOME//DTD DocBook PNG Variant V1.1//EN, please
(I'm looking for the home site of this DTD)?

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

[Scrollkeeper-devel] Distributed tar.gz Archive File

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

In addition to the .sgml files please distribute prebuilt .html files as
well.

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

[Scrollkeeper-devel] scrollkeeper.spec.in simplification

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

Please, apply the following patch.  Rationale:

. Avoid hard coded /usr/share (replaced by %{_datadir}
. This patch avoids absolute links
. use a 'for' loop for doing the same task over and over again (but
  treat 'en' and 'no' special.

If it isn't clear what I want to achieve please ask.

--- scrollkeeper-0.1.3/scrollkeeper.spec.in.~1~	Wed Feb 28 12:40:37 2001
+++ scrollkeeper-0.1.3/scrollkeeper.spec.in	Sun Mar  4 06:51:48 2001
@@ -33,62 +33,19 @@
 %install
 rm -rf $RPM_BUILD_ROOT
 %makeinstall
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/bg_BG
-ln -sf /usr/share/scrollkeeper/Templates/bg ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/bg_BG
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/bg_BG.cp1251
-ln -sf /usr/share/scrollkeeper/Templates/bg ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/bg_BG.cp1251
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/de_AT
-ln -sf /usr/share/scrollkeeper/Templates/de ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/de_AT
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/en
-ln -sf /usr/share/scrollkeeper/Templates/C ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/en
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/en_AU
-ln -sf /usr/share/scrollkeeper/Templates/en ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/en_AU
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/en_GB
-ln -sf /usr/share/scrollkeeper/Templates/en ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/en_GB
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/en_SE
-ln -sf /usr/share/scrollkeeper/Templates/en ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/en_SE
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/en_UK
-ln -sf /usr/share/scrollkeeper/Templates/en ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/en_UK
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/en_US
-ln -sf /usr/share/scrollkeeper/Templates/en ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/en_US
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/es_DO
-ln -sf /usr/share/scrollkeeper/Templates/es ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/es_DO
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/es_ES
-ln -sf /usr/share/scrollkeeper/Templates/es ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/es_ES
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/es_GT
-ln -sf /usr/share/scrollkeeper/Templates/es ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/es_GT
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/es_HN
-ln -sf /usr/share/scrollkeeper/Templates/es ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/es_HN
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/es_MX
-ln -sf /usr/share/scrollkeeper/Templates/es ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/es_MX
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/es_PA
-ln -sf /usr/share/scrollkeeper/Templates/es ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/es_PA
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/es_PE
-ln -sf /usr/share/scrollkeeper/Templates/es ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/es_PE
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/es_SV
-ln -sf /usr/share/scrollkeeper/Templates/es ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/es_SV
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/ja_JP.eucJP
-ln -sf /usr/share/scrollkeeper/Templates/ja ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/ja_JP.eucJP
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/no
-ln -sf /usr/share/scrollkeeper/Templates/nb ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/no
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/no_NY
-ln -sf /usr/share/scrollkeeper/Templates/nn ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/no_NY
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/pt_BR
-ln -sf /usr/share/scrollkeeper/Templates/pt ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/pt_BR
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/pt_PT
-ln -sf /usr/share/scrollkeeper/Templates/pt ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/pt_PT
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/sr_YU
-ln -sf /usr/share/scrollkeeper/Templates/sr ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/sr_YU
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/sv_SE
-ln -sf /usr/share/scrollkeeper/Templates/sv ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/sv_SE
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/zh_CN
-ln -sf /usr/share/scrollkeeper/Templates/zh ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/zh_CN
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/zh_CN.GB2312
-ln -sf /usr/share/scrollkeeper/Templates/zh ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/zh_CN.GB2312
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/zh_TW
-ln -sf /usr/share/scrollkeeper/Templates/zh ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/zh_TW
-rm -rf ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/zh_TW.Big5
-ln -sf /usr/share/scrollkeeper/Templates/zh ${RPM_BUILD_ROOT}/usr/share/scrollkeeper/Templates/zh_TW.Big5
+
+# mkdir -p ${RPM_BUILD_ROOT}%{_datadir}/scrollkeeper/Templates
+pushd ${RPM_BUILD_ROOT}%{_datadir}/scrollkeeper/Templates
+rm -fr en && ln -sf C en
+rm -fr no* && ln -sf nb no && ln -sf nn no_NY
+for lang in bg_BG bg_BG.cp1251 de_AT en_AU en_GB en_SE en_UK en_US es_DO es_ES \
+         es_ES es_GT es_HN es_MX es_PA es_PE es_SV ja_JP.eucJP pt_BR pt_PT sr_YU \
+         sv_SE zh_CN zh_CN.GB2312 zh_TW zh_TW.Big5 ; do
+    l=${lang%_*}
+    rm -fr $lang
+    ln -sf $l $lang
+done 
+popd
 
 %clean
 rm -rf $RPM_BUILD_ROOT

Diff finished at Sun Mar  4 06:51:59

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