scrollkeeper-devel Mailing List for ScrollKeeper (Page 38)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

ScrollKeeper: Open Source Document Management
http://www.xml.com/pub/a/2001/11/28/scrollkeeper.html

Best,
Kendall Clark

SKers,

I have a roughly 3,000 word piece about SK forthcoming on O'Reilly's
XML.com. Scheduled to appear this week, though it may slip.

Best,
Kendall Clark
Columns Editor, XML.com

ScrollServer 0.6 has been released. It's on its own domain now,
www.scrollserver.org.

ScrollServer now serves all documents in the ScrollKeeper database.

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

If one company dominates everything, it's dangerous. You kill innovation and
you lose the capacity to create alternatives. Ultimately, that isn't good
for the consumer or the country.
	--Samuel Miller, U.S. Justice Department

On Thu, 27 Sep 2001, David Merrill wrote:

> On Thu, Sep 27, 2001 at 01:57:07PM -0400, Alexander Kirillov wrote:
> >
> >
> > > >
> > > > I think we have a need for a special help URI scheme.  I would also like
> > > > to get away from a proliferation of help schemes and come up with a single
> > > > (good) help:// scheme which we all share.  This would make things simpler
> > > > in the long term.  We do have to handle a few interesting problems though.
> > > > eg: Does "help://cdplayer" give you the GNOME cd player application or the
> > > > KDE cd player application, or neither?  How do you handle multiple
> > > > documents with the same URI (eg. different versions, languages, formats,
> > > > etc. of a given document)? How do you handle targets for both HTML and XML
> > > > documents at the same time?
> >
> > The obvious idea would be for every application, add to OMF one more
> > field, "identifier" and try to keep it unique. For application
> > manuals, it should probably be the same as binary name: for Nautilus,
> > "id" should be "nautilus". Thus, GNOME cd player will have identifier
> > "gtcd" while for KDE player, it is "kscd". This almost guarantees
> > uniqueness. As for different formats/versions/languages - the help
> > browser must have some built in (probably configurable) preferences:
> > e.g., use the language of "locale", latest version, etc.
>
> What about program-name-1.1.1 so both name and version are extractable
> directly?

One of the primary needs for the URI is so that documents can cross
reference each other.  If the docs for program-a-1.0 references the docs
for program-b-1.0 and the user upgrades to program-b-1.1 without updating
program-a, then the documentation will break.  So, having a very generic
URI is more useful than a specific URI.  Similarly, I don't think we want
to use a URN for this purpose, as I believe a URN is the limit of complete
specificity including locale, format, etc. except for physical location of
the file.

I do like the idea of URN's, but I haven't figured out how they can fit
into ScrollKeeper.  They may be valuable when ScrollKeeper becomes
network-enabled and has to locate remote documents.

Dan

On Thu, Sep 27, 2001 at 01:43:57AM -0500, Dan Mueth wrote:
> 
> On Tue, 18 Sep 2001, David Merrill wrote:
> 
> > Hi,
> >
> > What is the recommended way to get a list of documents? The contents
> > list and extended contents list are not a list of documents -- the
> > same document is often listed more than once in separate sections.
> >
> > I'm trying to generate all my web pages with xslt, so I'm looking for
> > a way to extract a list of documents, sorted, and write out html. I'm
> > doing okay so far learning xslt, but there doesn't seem to be a way to
> > do this without a clever hack, and I would rather find a more
> > straightforward way.
> 
> Hmm.. We don't have any files containing each document exactly once which
> is exported for use by other applications.  I hadn't thought of a need for
> it before you suggested this one.
> 
> You could work around it by extracting a unique list from the contents
> list. It sounds like this is what you are doing. The alternate would be to
> modify ScrollKeeper to keep this data in another XML file and then export
> the information.  If we think many applications will need the list, then
> this is the better approach.  If you actually want to use it soon, this
> would mean churning out a 0.2.1 release.  It would not need too much
> changing to roll it into 0.3.0.

I found a way. I just have an XSL stylesheet that does a sort on the
documents, then drops duplicates.

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

We have increased our prices over the last 10 years [while] other component
prices have come down and continue to come down.
	--Microsoft Senior VP Joachim Kempin

On Thu, Sep 27, 2001 at 01:57:07PM -0400, Alexander Kirillov wrote:
> 
> 
> > > 
> > > I think we have a need for a special help URI scheme.  I would also like
> > > to get away from a proliferation of help schemes and come up with a single
> > > (good) help:// scheme which we all share.  This would make things simpler
> > > in the long term.  We do have to handle a few interesting problems though.
> > > eg: Does "help://cdplayer" give you the GNOME cd player application or the
> > > KDE cd player application, or neither?  How do you handle multiple
> > > documents with the same URI (eg. different versions, languages, formats,
> > > etc. of a given document)? How do you handle targets for both HTML and XML
> > > documents at the same time?
> 
> The obvious idea would be for every application, add to OMF one more
> field, "identifier" and try to keep it unique. For application
> manuals, it should probably be the same as binary name: for Nautilus,
> "id" should be "nautilus". Thus, GNOME cd player will have identifier
> "gtcd" while for KDE player, it is "kscd". This almost guarantees
> uniqueness. As for different formats/versions/languages - the help
> browser must have some built in (probably configurable) preferences:
> e.g., use the language of "locale", latest version, etc. 

What about program-name-1.1.1 so both name and version are extractable
directly?

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

Asked how small software companies could compete on products that Microsoft
wants to fold into Windows, [Microsoft COO Bob] Herbold told Bloomberg News
they could either fight a losing battle, sell out to Microsoft or a larger
company or 'not go into business to begin with.'
	--Newsweek, March 1998

> > 
> > I think we have a need for a special help URI scheme.  I would also like
> > to get away from a proliferation of help schemes and come up with a single
> > (good) help:// scheme which we all share.  This would make things simpler
> > in the long term.  We do have to handle a few interesting problems though.
> > eg: Does "help://cdplayer" give you the GNOME cd player application or the
> > KDE cd player application, or neither?  How do you handle multiple
> > documents with the same URI (eg. different versions, languages, formats,
> > etc. of a given document)? How do you handle targets for both HTML and XML
> > documents at the same time?

The obvious idea would be for every application, add to OMF one more
field, "identifier" and try to keep it unique. For application
manuals, it should probably be the same as binary name: for Nautilus,
"id" should be "nautilus". Thus, GNOME cd player will have identifier
"gtcd" while for KDE player, it is "kscd". This almost guarantees
uniqueness. As for different formats/versions/languages - the help
browser must have some built in (probably configurable) preferences:
e.g., use the language of "locale", latest version, etc. 

Sasha

On Tue, 18 Sep 2001, David Merrill wrote:

> Hi,
>
> What is the recommended way to get a list of documents? The contents
> list and extended contents list are not a list of documents -- the
> same document is often listed more than once in separate sections.
>
> I'm trying to generate all my web pages with xslt, so I'm looking for
> a way to extract a list of documents, sorted, and write out html. I'm
> doing okay so far learning xslt, but there doesn't seem to be a way to
> do this without a clever hack, and I would rather find a more
> straightforward way.

Hmm.. We don't have any files containing each document exactly once which
is exported for use by other applications.  I hadn't thought of a need for
it before you suggested this one.

You could work around it by extracting a unique list from the contents
list. It sounds like this is what you are doing. The alternate would be to
modify ScrollKeeper to keep this data in another XML file and then export
the information.  If we think many applications will need the list, then
this is the better approach.  If you actually want to use it soon, this
would mean churning out a 0.2.1 release.  It would not need too much
changing to roll it into 0.3.0.

If you'd like a really dirty hack, you could just snoop on the internal
ScrollKeeper file:
	`scrollkeeper-config --pkglocalstatedir`/scrollkeeper_docs

This may make things easier for playing around in the short term, but
should not be used for any real releases since this file is not meant to
be exported.

Dan

On Wed, Sep 26, 2001 at 01:59:17AM -0500, Dan Mueth wrote:
> 
> [cc'ing scrollkeeper-devel, since this is more about scrollkeeper than
> GNOME specifically]
> 
> On Sat, 22 Sep 2001, David Merrill wrote:
> 
> > On Sun, Sep 23, 2001 at 07:00:15AM +0800, Malcolm Tredinnick wrote:
> > > Other help browsers and document viewers which are more tightly tied to
> > > GNOME will also be able able to parse the DocBook XML and _will_
> > > understand the "ghelp://" or "gnome-help://" or whatever-it-is-this-
> > > month scheme.
> >
> > What benefit do you gain from using gnome-help:// instead of http://?
> > I guess I just fail to see any advantage to using a gnome-specific
> > url. The whole point of ScrollKeeper was to build a unified and
> > consistent database rather than more of the hodgepodge we have today.
> > Let's not create more hodgepodge now that we have a chance to do it
> > cleanly and standards-based.
> 
> I think we need a special URI scheme since we need to effectively separate
> the namespace and provide a special resolution system.  For example, the
> Gnumeric Manual needs to link to the GFDL DocBook doc.  However, the GFDL
> doc was shipped with gnome-core, so the gnumeric package doesn't know the
> path to the GFDL file or its format.  The link is done as "ghelp:gfdl" and
> then something (right now it is a combination of gnome-libs and gnome-vfs
> I believe) resolves the full path to the GFDL file (which may be in SGML,
> XML, or HTML BTW), including any target.

Then maybe the approach to take is to to with a URN rather than a URL?
The whole point of a URN is that it is not location specific, which
means the help browser (or consumer of ScrollKeeper, whoever that
might be) would be able to resolve the URN and location the resource
from some other location.

Unfortunately URNs aren't as well known as URLs, and obtaining and
defining a namespace is a big job, potentially.

In the longer term, we should look at newer XML functionality such as
XLink, XPath and XPointer, which all attempt to resolve these issues.

> > > My understanding is that ScrollKeeper stores meta-information about
> > > documents in a non-application-specific fashion. The problem you are
> > > running into is that web browsers need to be set up especially to
> > > understand a certain type of valid URI. You can handle that (nicely, in
> > > my view) with the dynamic rewrite above and leave the ghelp:// reference
> > > there for those applications which can handle it differently.
> >
> > No, there won't be any applications which can handle it differently.
> > We'll all be handling it the same, but we'll also all be handling
> > kde's format and regular http:// format as well. So each of us will
> > have three blocks of code instead of one. It's extra effort for
> > everyone with no benefit to anyone. It's ugly.
> >
> > If you can come up with some real benefit of using gnome-help://, then
> > we should *all* use that format -- but just help:// please. :-)
> 
> I think we have a need for a special help URI scheme.  I would also like
> to get away from a proliferation of help schemes and come up with a single
> (good) help:// scheme which we all share.  This would make things simpler
> in the long term.  We do have to handle a few interesting problems though.
> eg: Does "help://cdplayer" give you the GNOME cd player application or the
> KDE cd player application, or neither?  How do you handle multiple
> documents with the same URI (eg. different versions, languages, formats,
> etc. of a given document)? How do you handle targets for both HTML and XML
> documents at the same time?

I'll have to go reread the appropriate RFC to be sure, but I don't
think that kind of URI is provided for in the spec. That's why I want
to look at a URN, which does allow for `custom' applications.

> I think we can come up with reasonable answers to these questions.  Then
> it is just a matter of adding a new element or attribute to the OMF and a
> bit of code to ScrollKeeper to do the URI resolution.
> 
> I'd be particularly interested to hear opinions from the KDE folks.

Yes, this is a global issue. It's also, unfortunately, going to be a
sticky one.

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

The number of error messages we put in front of people is a tragedy.
	--David Cole, general manager of Microsoft's consumer division
	  (The Register, 09-02-99)

[cc'ing scrollkeeper-devel, since this is more about scrollkeeper than
GNOME specifically]

On Sat, 22 Sep 2001, David Merrill wrote:

> On Sun, Sep 23, 2001 at 07:00:15AM +0800, Malcolm Tredinnick wrote:
> > Other help browsers and document viewers which are more tightly tied to
> > GNOME will also be able able to parse the DocBook XML and _will_
> > understand the "ghelp://" or "gnome-help://" or whatever-it-is-this-
> > month scheme.
>
> What benefit do you gain from using gnome-help:// instead of http://?
> I guess I just fail to see any advantage to using a gnome-specific
> url. The whole point of ScrollKeeper was to build a unified and
> consistent database rather than more of the hodgepodge we have today.
> Let's not create more hodgepodge now that we have a chance to do it
> cleanly and standards-based.

I think we need a special URI scheme since we need to effectively separate
the namespace and provide a special resolution system.  For example, the
Gnumeric Manual needs to link to the GFDL DocBook doc.  However, the GFDL
doc was shipped with gnome-core, so the gnumeric package doesn't know the
path to the GFDL file or its format.  The link is done as "ghelp:gfdl" and
then something (right now it is a combination of gnome-libs and gnome-vfs
I believe) resolves the full path to the GFDL file (which may be in SGML,
XML, or HTML BTW), including any target.

> > My understanding is that ScrollKeeper stores meta-information about
> > documents in a non-application-specific fashion. The problem you are
> > running into is that web browsers need to be set up especially to
> > understand a certain type of valid URI. You can handle that (nicely, in
> > my view) with the dynamic rewrite above and leave the ghelp:// reference
> > there for those applications which can handle it differently.
>
> No, there won't be any applications which can handle it differently.
> We'll all be handling it the same, but we'll also all be handling
> kde's format and regular http:// format as well. So each of us will
> have three blocks of code instead of one. It's extra effort for
> everyone with no benefit to anyone. It's ugly.
>
> If you can come up with some real benefit of using gnome-help://, then
> we should *all* use that format -- but just help:// please. :-)

I think we have a need for a special help URI scheme.  I would also like
to get away from a proliferation of help schemes and come up with a single
(good) help:// scheme which we all share.  This would make things simpler
in the long term.  We do have to handle a few interesting problems though.
eg: Does "help://cdplayer" give you the GNOME cd player application or the
KDE cd player application, or neither?  How do you handle multiple
documents with the same URI (eg. different versions, languages, formats,
etc. of a given document)? How do you handle targets for both HTML and XML
documents at the same time?

I think we can come up with reasonable answers to these questions.  Then
it is just a matter of adding a new element or attribute to the OMF and a
bit of code to ScrollKeeper to do the URI resolution.

I'd be particularly interested to hear opinions from the KDE folks.

Dan

On Wed, Sep 19, 2001 at 09:52:33AM +0200, Ismael Olea wrote:
> David Merrill escribió:
> > 
> > Hi,
> > 
> > What is the recommended way to get a list of documents? The contents
> > list and extended contents list are not a list of documents -- the
> > same document is often listed more than once in separate sections.
> > 
> > I'm trying to generate all my web pages with xslt, so I'm looking for
> > a way to extract a list of documents, sorted, and write out html. I'm
> > doing okay so far learning xslt, but there doesn't seem to be a way to
> > do this without a clever hack, and I would rather find a more
> > straightforward way.
> > 
> 
> I think xslt is good but solves only a part of the problem. You'll need
> something like wml/eperl/php or similar.

I'm hoping to use only xslt for this particular part of the problem.
The rest I'm doing with Python.

> Do you have your code accesible with cvs?

It's in the LDP cvs under /LDP/scrollserver

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

Ismael Olea escribió:

> I think xslt is good but solves only a part of the problem. You'll need
> something like wml/eperl/php or similar.

I mean «...something _more_ like...»

:-)

> 
> Do you have your code accesible with cvs?

-- 
	A.Ismael Olea González

	mailto:is...@ol... mailto:ol...@hi...
	http://slug.hispalinux.es/~olea

	El mundo debe empezar a tener miedo a un planeta OLEA

David Merrill escribió:
> 
> Hi,
> 
> What is the recommended way to get a list of documents? The contents
> list and extended contents list are not a list of documents -- the
> same document is often listed more than once in separate sections.
> 
> I'm trying to generate all my web pages with xslt, so I'm looking for
> a way to extract a list of documents, sorted, and write out html. I'm
> doing okay so far learning xslt, but there doesn't seem to be a way to
> do this without a clever hack, and I would rather find a more
> straightforward way.
> 

I think xslt is good but solves only a part of the problem. You'll need
something like wml/eperl/php or similar.

Do you have your code accesible with cvs?

-- 
	A.Ismael Olea González

	mailto:is...@ol... mailto:ol...@hi...
	http://slug.hispalinux.es/~olea

	El mundo debe empezar a tener miedo a un planeta OLEA

Hi,

What is the recommended way to get a list of documents? The contents
list and extended contents list are not a list of documents -- the
same document is often listed more than once in separate sections.

I'm trying to generate all my web pages with xslt, so I'm looking for
a way to extract a list of documents, sorted, and write out html. I'm
doing okay so far learning xslt, but there doesn't seem to be a way to
do this without a clever hack, and I would rather find a more
straightforward way.

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

Hi All,

Dan asked me to write down the current status of the project. 

As far as indexing is concerned Mary sent an email to the list a coupel
of days ago about this.

Everything we have in the CVS now is described in the
scrollkeeper-spec.txt document in the CVS. I updated this a couple of
months ago (my last contribution to Scrollkeeper was at the middle of
July). Since then there was no significant change to the source tree.

Dan has the best ideas about where the project needs to develop from
here.

A couple of small issues and implementation related details that have to
be done are:

1. File locks:

This is about concurrent access to Scrollkeeper databases. In case of
networked Scrollkeeper databases visible for a large number of users and
sysadmins a file locking mechanism has to be implemented during
accessing the databases.

2. popen() calls (security):

There are a couple of popen() calls in Scrollkeeper that are potential
security wholes. The usage of popen() calls is discouraged in code that
wants to be secure.

3. File format improvements: 

This was a long discussed issue, we got to an agreement (it is on the
mailing list), but I never had time to do it. During developing
Scrollkeeper I was asked to have a look at JavaHelp for potential
cooperation between the two systems or just avoiding to reinvent things.
THe JavaHelp metadata formats are in many ways similar to Scrollkeeper,
in some cases superior to that. I suggested changes to the Scrollkeeper
file formats that were accepted, but I never had time to implement them.

4. Relocatable package support:

This is an old issue and there is a solution for it on the mailing list.
Scrollkeeper updates the metadata with the document locations at build
time of the package based on $prefix (in an autoconf and automake
environment). This does not allow relocatable packages.

5. Networked Scrollkeeper database:

I mentioned this before, there is no support for two levels of
Scrollkeeper databases, one for a large number of users (central) and
one for the user only (private). These two merged would give the total
number of documents the user can access.

6. Test plan:

The Sun Gnome team committed to write a test plan for Scrollkeeper and a
test suite in the future. I don't have any idea what is going to happen
with this, a little work has been done in this area only. In case people
want to find out if this is still happening, Leo Binchy
(leo...@su...) should be contacted.

7. OMF directory configuration:

This issue is partly resolved. THe idea is to implement a flexible way
of specifying where to look for OMF metadata files. Right now there are
three ways of doing this, on the command line, through and environment
variable and through a /etc/scrollkeeper.conf file. This is all
implemented. There is one unimplemented idea, namely that at configure
time we should be able to specify through a --omfdirs type of flag the
content of /etc/scrollkeeper.conf. This has been discussed on the
mailing list.

9. Category tree definition:

Very old one, we have an enforced category tree and we had various ideas
about should we enforce a fixed tree on the user or not (discussed a lot
on the mailing list). This will probably need changes once Scrollkeeper
gets tried in real life.

That's all, I hope this helps. Let me know if you have any questions.

Laszlo

On Fri, Sep 07, 2001 at 12:36:26AM -0500, Dan Mueth wrote:
> 
> On Thu, 6 Sep 2001, David Merrill wrote:
> > When will you add man pages?
> >
> > When will you add info pages?
> >
> > Do you have, or wish to have, a script that searches for man/info
> > pages and adds them to the database? If so, how should it work?
> 
> I'm still unsure of how we want to deal with man and info pages.
> ScrollKeeper doesn't have a whole lot to add here, since I doubt anybody
> will want to write up OMF files for every man and info page out there.
> I am guessing we will want to use some sort of a script which looks at
> certain paths and extracts the info naturally embedded in these formats.
> While this will be much more limitted than what we can do with
> DocBook/OMF, I think it will still be a nice feature.  This is another
> really good project for any hacker who is interested.

Hehe. See http://www.tuxedo.org/~esr/doclifter/

It converts man pages to docbook sgml or xml. :-)

One step in the right direction!

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

On Mon, Sep 17, 2001 at 06:18:10PM +0200, Martijn van Beers wrote:
> Hi,
> 
> I really didn't like creating a .omf file by hand when half of
> the information in it is already in my source docbook file, so
> I wrote a little xsl stylesheet to get that info out. To get
> the other information at the same time, I put it in the docbook
> file using namespaces.
> 
> Attached are the stylesheet, an example document and the output
> from running xsltproc with those.

Very cool.

Greg Ferguson wrote a perl script that does omf extraction also, but
it looks like this is a better solution.

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

Hi,

I really didn't like creating a .omf file by hand when half of
the information in it is already in my source docbook file, so
I wrote a little xsl stylesheet to get that info out. To get
the other information at the same time, I put it in the docbook
file using namespaces.

Attached are the stylesheet, an example document and the output
from running xsltproc with those.

Martijn

On Tue, 11 Sep 2001, David Merrill wrote:

> On Mon, Sep 10, 2001 at 10:52:50PM -0500, Dan Mueth wrote:
> > > Can I assume all binaries will be in the same directory that the
> > > source sgml file is in? I suppose this would be a packaging
> > > requirement for scrollkeeper?
> >
> > No, you can't assume that.  In fact, you'll find that most GNOME documents
> > place their screenshots in a subdirectory called figures/, or sometimes
> > even figs/ or images/. In  other cases, you'll find entities in a
> > subdirectory as well.  I expect this to be common in non-GNOME documents
> > as well.
>
> I should have said, or in a subdirectory. Would it be too much of a
> restriction to require (not require really, like it's a condition for
> getting into scrollkeeper, but mentioned in the packaging
> documentation) for scrollkeeper?

I'd like to avoid this sort of constraint if possible.

Dan

On Mon, Sep 10, 2001 at 10:52:50PM -0500, Dan Mueth wrote:
> > Can I assume all binaries will be in the same directory that the
> > source sgml file is in? I suppose this would be a packaging
> > requirement for scrollkeeper?
> 
> No, you can't assume that.  In fact, you'll find that most GNOME documents
> place their screenshots in a subdirectory called figures/, or sometimes
> even figs/ or images/. In  other cases, you'll find entities in a
> subdirectory as well.  I expect this to be common in non-GNOME documents
> as well.

I should have said, or in a subdirectory. Would it be too much of a
restriction to require (not require really, like it's a condition for
getting into scrollkeeper, but mentioned in the packaging
documentation) for scrollkeeper?

If they can be anywhere, I guess I could just set a baseref in the
generated html and that might take care of it. I'll have to try a test
case.

Thanks,

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

Free Dmitry Sklyarov!  http://www.freesklyarov.org
Washington DC Protests http://www.lupercalia.net/dmca

On Mon, 10 Sep 2001, David Merrill wrote:

> I'm having a problem with serving the images that are referenced in
> docbook documents in scrollkeeper. What is the plan for identifying
> them, and any other binaries that might be a part of the document?

There are no plans for this.  The main assumption I've been working on is
that there is always one main document file, and that any other files
needed are known about by this file or by the document processor for the
particular file type. (eg. HTML and DocBook files typically refer to
images by their relative path.  DocBook docs typically need a DTD and
stylesheet, but it is assumed that your DocBook setup understands how to
find these files.)

> Can I assume all binaries will be in the same directory that the
> source sgml file is in? I suppose this would be a packaging
> requirement for scrollkeeper?

No, you can't assume that.  In fact, you'll find that most GNOME documents
place their screenshots in a subdirectory called figures/, or sometimes
even figs/ or images/. In  other cases, you'll find entities in a
subdirectory as well.  I expect this to be common in non-GNOME documents
as well.

Generally, we wanted ScrollKeeper to place as few restrictions and burdens
on its users (ie. doc writers, hackers, and packagers) as possible.  In
particular, we didn't want to restrict what document formats people use or
where the documents are stored.

Dan

I'm having a problem with serving the images that are referenced in
docbook documents in scrollkeeper. What is the plan for identifying
them, and any other binaries that might be a part of the document?

Can I assume all binaries will be in the same directory that the
source sgml file is in? I suppose this would be a packaging
requirement for scrollkeeper?

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

Free Dmitry Sklyarov!  http://www.freesklyarov.org
Washington DC Protests http://www.lupercalia.net/dmca

hi

yes, the index support is complete and putback.
The index.xsl stylesheet will process indexterms that use the id or zone 
attributes. 
It will ignore indexterms that do not use these attributes to provide anchors 
into the original document. Dealing with such indexterms would, I believe, 
involve preprocessing the original document to insert id attributes with 
generated id values (could be done with an xsl stylesheet ?). And then applying 
the index.xsl stylesheet as normal. Unfortunately, I will not have the time to 
address this.

regards
Mary

> 
> 
> Yes. I am not sure how finished this is, I'll find out, but I think it
> is finished.
> 
> Laszlo
> 
> > 
> > Does this include Mary's index support?
> > 
> > --
> > John Fleck
> > jf...@in... (h), http://www.inkstain.net/fleck/
> > 
> > _______________________________________________
> > Scrollkeeper-devel mailing list
> > Scr...@li...
> > https://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel
> 
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> https://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel

Yes. I am not sure how finished this is, I'll find out, but I think it
is finished.

Laszlo

> 
> Does this include Mary's index support?
> 
> --
> John Fleck
> jf...@in... (h), http://www.inkstain.net/fleck/
> 
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> https://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel

On Mon, Sep 10, 2001 at 10:08:01AM -0500, Dan Mueth wrote:
> 
> 
> On Fri, 7 Sep 2001, David Merrill wrote:
> 
> > What is the plan for 0.3, and is there an estimated release date?
> 
> I think Laszlo and Mary have basically finished adding the rather long new
> feature list to take us from 0.2 to 0.3.  Laszlo will send out a summary
> of where things stand next week when he gets back from his holiday.
> 

Does this include Mary's index support?

-- 
John Fleck
jf...@in... (h), http://www.inkstain.net/fleck/

2000	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (5)	Oct (50)	Nov (117)	Dec (38)
2001	Jan (7)	Feb (7)	Mar (40)	Apr (83)	May (72)	Jun (15)	Jul (8)	Aug (1)	Sep (29)	Oct	Nov (6)	Dec (4)
2002	Jan (8)	Feb (4)	Mar (18)	Apr (27)	May (70)	Jun (21)	Jul (13)	Aug (27)	Sep (2)	Oct (26)	Nov (1)	Dec (6)
2003	Jan (17)	Feb (9)	Mar (4)	Apr (14)	May (18)	Jun (25)	Jul (4)	Aug (11)	Sep (14)	Oct (6)	Nov (5)	Dec (22)
2004	Jan (16)	Feb (3)	Mar (7)	Apr (2)	May (4)	Jun	Jul (3)	Aug (4)	Sep	Oct	Nov	Dec
2005	Jan	Feb	Mar (5)	Apr (1)	May (3)	Jun (2)	Jul (5)	Aug (2)	Sep (2)	Oct (3)	Nov (7)	Dec (6)
2006	Jan (3)	Feb (3)	Mar (1)	Apr (2)	May (6)	Jun (21)	Jul (12)	Aug (7)	Sep (10)	Oct (34)	Nov (21)	Dec (28)
2007	Jan (29)	Feb (39)	Mar (25)	Apr (39)	May (26)	Jun (12)	Jul (16)	Aug (42)	Sep (24)	Oct (11)	Nov (8)	Dec (6)
2008	Jan (10)	Feb (9)	Mar (30)	Apr (19)	May (16)	Jun (10)	Jul (27)	Aug (22)	Sep (23)	Oct (18)	Nov (21)	Dec (51)
2009	Jan (56)	Feb (39)	Mar (45)	Apr (49)	May (108)	Jun (109)	Jul (66)	Aug (33)	Sep (26)	Oct (41)	Nov (13)	Dec (14)
2010	Jan (6)	Feb (7)	Mar (36)	Apr (50)	May (74)	Jun (61)	Jul (33)	Aug (58)	Sep (29)	Oct	Nov (1)	Dec
2011	Jan (1)	Feb (2)	Mar (3)	Apr (1)	May (1)	Jun (2)	Jul (2)	Aug (1)	Sep (1)	Oct (3)	Nov	Dec
2012	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug (2)	Sep	Oct	Nov	Dec
2013	Jan (1)	Feb	Mar (1)	Apr	May (2)	Jun	Jul (1)	Aug (2)	Sep (2)	Oct (2)	Nov	Dec
2014	Jan (3)	Feb	Mar (3)	Apr (1)	May (1)	Jun	Jul (2)	Aug	Sep (6)	Oct (6)	Nov (5)	Dec (1)
2015	Jan (2)	Feb (3)	Mar (2)	Apr (1)	May (3)	Jun	Jul	Aug	Sep	Oct (1)	Nov (1)	Dec (2)
2016	Jan	Feb	Mar	Apr	May (1)	Jun (3)	Jul	Aug (3)	Sep	Oct	Nov	Dec
2017	Jan	Feb (1)	Mar (2)	Apr (3)	May	Jun (1)	Jul (1)	Aug	Sep	Oct	Nov	Dec
2018	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (3)	Oct (1)	Nov	Dec (2)
2019	Jan (1)	Feb (2)	Mar (3)	Apr	May (1)	Jun (4)	Jul	Aug	Sep	Oct (1)	Nov (3)	Dec
2020	Jan (2)	Feb (1)	Mar	Apr	May	Jun	Jul	Aug	Sep (2)	Oct (1)	Nov	Dec (1)
2021	Jan	Feb (2)	Mar (6)	Apr (4)	May (3)	Jun (2)	Jul (5)	Aug (18)	Sep (13)	Oct (19)	Nov (35)	Dec (23)
2022	Jan (6)	Feb (10)	Mar (6)	Apr (1)	May	Jun	Jul	Aug (2)	Sep (2)	Oct (1)	Nov	Dec
2023	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct (1)	Nov (1)	Dec
2024	Jan	Feb (1)	Mar	Apr	May (1)	Jun	Jul	Aug (1)	Sep	Oct (2)	Nov	Dec
2025	Jan	Feb	Mar	Apr	May	Jun (1)	Jul (1)	Aug (1)	Sep (1)	Oct (1)	Nov (5)	Dec (4)
2026	Jan (1)	Feb (4)	Mar	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

scrollkeeper-devel Mailing List for ScrollKeeper (Page 38)

scrollkeeper-devel — Developer discussion list for ScrollKeeper