scrollkeeper-devel — Developer discussion list for ScrollKeeper

[Scrollkeeper-devel] distchecking a package with scrollkeeper docs

[Andy W. <wi...@po...>]

Hi all,

I was wondering how to make a package with scrollkeeper docs pass
distcheck. I use the latest omf.make, etc, which makes my omfs get
installed and deinstalled properly, but since scrollkeeper-update
creates a whole new cache in =inst/var, obviously files are left over
afer uninstalling. Is there any way to get around this?

Thanks in advance,

Andy

[Scrollkeeper-devel] scrollkeeper-get-content-list error

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

Folks -

When trying to run scrollkeeper-get-content-list[1], I get the following
errors:

[jfleck@jelloiii scrollkeeper-0.3.11]$ scrollkeeper-get-content-list C
warning: failed to load external entity
"/var/lib/scrollkeeper/en_US/scrollkeeper_cl.xml"
/tmp/scrollkeeper-tempfile.2
[jfleck@jelloiii scrollkeeper-0.3.11]$ scrollkeeper-get-content-list da
warning: failed to load external entity
"/var/lib/scrollkeeper/en_US/scrollkeeper_cl.xml"
/tmp/scrollkeeper-tempfile.2

There is no "/var/lib/scrollkeeper/en_US/scrollkeeper_cl.xml".

What am I doing wrong?
Cheers,
John

[1] This is with 3.11.
-- 
John Fleck
jf...@in... (h) jf...@ab... (w)
http://www.inkstain.net http://www.abqjournal.com

"Sometimes, a diner is all about the mac and cheese." 
  - Zippy the Pinhead

Re: [Scrollkeeper-devel] Translated TOC list.

[Mikael H. <mi...@co...>]

s=F6n 2002-08-04 klockan 19.00 skrev Dan Mueth:

> > Anyway, what I noticed is that the title-element on the GNOME-sect was
> > missing (not sure why?) Help would be greatly appreciated.
>=20
> I'm not sure what you are referring to here.

When using 'C' as locale (I guess that is what scrollkeeper falls back
to if it doesn't find the locale passed to it).

I have a section like this:

<sect>
  <title>GNOME</title>
  <sect>
    <title>Some subsection</title>
  ...
</sect>

but when I use the 'sv' (or any other I tried) locale it looks like
this:

<sect>
  <sect>
    <title>Some subsection</title> (of course translated)
  ...
</sect>

Not sure why this happens but it ruins my use of Scrollkeeper :)
Could it be if the translation hasn't translated 'GNOME' and it doesn't
fall back to the original string?

Regards,
  Mikael Hallendal

--=20
Mikael Hallendal                mi...@co...
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918

Re: [Scrollkeeper-devel] Translated TOC list.

[Dan M. <mu...@al...>]

On 4 Aug 2002, Mikael Hallendal wrote:

> Hi!
> 
> If I do a pretty ugly hack and remove everything after _ in the locale
> when calling scrollkeeper-get-content-list I get a translated TOC-file.
> IMHO you should be able to call it with locale sv_SE or sv_SE.ISO8859-1
> and still get the correct TOC-file.

Hi.

Where does this sort of locale fallback usually happen?  It looks like
glibc does not do it, but for Gtk+ applications, GDK does it. It would
make sense, then, to move it from Yelp into Scrollkeeper.

> Anyway, what I noticed is that the title-element on the GNOME-sect was
> missing (not sure why?) Help would be greatly appreciated.

I'm not sure what you are referring to here.

Dan

Re: [Scrollkeeper-devel] Using a different scrollkeeper database from the standard one

[Dan M. <mu...@al...>]

Hi Martin,

Unfortunately the current ScrollKeeper version doesn't do everything that
is needed to get this to work properly.  As you can see, we have some
parts of this done (like allowing you to create databases anywhere you
have write access), but we still need to add flags to some of the scripts,
allow for a log file which is not in /var/log, allow for
$HOME/.scrollkeeper.conf, and a couple other things.  It has been on the
TODO list for some time, but until now nobody has voiced an interested in
using this capability.

-Dan


On 2 Aug 2002, Martin Carmueja wrote:

> Hello everybody. 
> 
> I've been trying ScrollKeeper these days, and I've been able to create a
> database on my home directory, and install OMF files from a specific
> path (by declaring a customized OMF_DIR environment variable). I would
> like now this database to be available for my help browser (yelp in my
> case) instead of the system-wide database. How could I do this? Am I
> completely lost? :-) . 
> 
> Thank you.
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> https://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel
> 

[Scrollkeeper-devel] Translated TOC list.

[Mikael H. <mi...@co...>]

Hi!

If I do a pretty ugly hack and remove everything after _ in the locale
when calling scrollkeeper-get-content-list I get a translated TOC-file.
IMHO you should be able to call it with locale sv_SE or sv_SE.ISO8859-1
and still get the correct TOC-file.

Anyway, what I noticed is that the title-element on the GNOME-sect was
missing (not sure why?) Help would be greatly appreciated.

Regards,
  Mikael Hallendal

-- 
Mikael Hallendal                mi...@co...
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918

[Scrollkeeper-devel] Using a different scrollkeeper database from the standard one

[Martin C. <mca...@ig...>]

Hello everybody. 

I've been trying ScrollKeeper these days, and I've been able to create a
database on my home directory, and install OMF files from a specific
path (by declaring a customized OMF_DIR environment variable). I would
like now this database to be available for my help browser (yelp in my
case) instead of the system-wide database. How could I do this? Am I
completely lost? :-) . 

Thank you.

[Scrollkeeper-devel] ScrollKeeper 0.3.11 Released

[Dan M. <mu...@al...>]

ScrollKeeper 0.3.11 is now available.

New in this release:
   * New categories added to allow document locations to more closely
     match the application locations in the GNOME Panel
   * Updated Slovak translations.

You can get ScrollKeeper 0.3.11 at:
        http://sourceforge.net/projects/scrollkeeper

If you find any bugs, please submit them to the bug tracker at:
        http://sourceforge.net/tracker/?group_id=11543&atid=111543
Please be sure to include your name and email address in any bugs you
enter so we can contact you if necessary.

If you would like to contribute to ScrollKeeper:
There are instructions for getting the latest source from CVS at:
        http://scrollkeeper.sourceforge.net/cvs.shtml
Look over the TODO list in the tarball or CVS and the bug list on the web,
find something you're interested in working on, and email
scr...@li... with your choice so that others
don't duplicate your work.

- The ScrollKeeper Team

[Scrollkeeper-devel] Re: Shortened titles in OMFs and Yelp

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

I appear to have lost the beginning of this thread, so pay no attention
to the threading.  I believe I've read the whole thread, via the web
archives at mail.gnome.org.

It seems that the discussion is about what titles should be, in terms of
content, and in terms of length.  I figure the best place to start
looking at the needs and uses for a title in documentation is DocBook,
since it's been around longer than OMF, Yelp, and the GDP combined, and
it has a much wider range of users, some of whom would probably have put
in RFEs if the existing title elements were insufficient.  The elements
which seem immediately relavent to this discussion are:
subtitle
title
titleabbrev

Titleabbrev seems to be what folks want, and it's description in TDG
states, "TitleAbbrev holds an abbreviated version of a Title.  One
common use of TitleAbbrev is for the text used in running headers or
footers, when the proper title is too long to be used conviently."

Does anybody see a reason not to simply adopt the element from DocBook
for use in OMF?  Eventually, we'll want DocBook and OMF metadata
elements to have a 1 to 1 mapping, so doing something else seems to be
just asking for more work down the road.


As for GNOME documents using long, ungaingly titles...  Eugene quoted a
bit from the GFDL as the reason that titles have gotten to be quite so
long.  I went and read over a copy of the GFDL, looking for that text. 
It appears in section 4, which is titaled "MODIFICATIONS".  This section
appears to apply to modifications and derivatives of the original work. 
I'd have to say that in most cases, we're not going to need to worry
about having a distinct title from that of the Document when we release
a new version of a manual, even if the original author disappears.  All
the documents from the GDP are written with the intent that they're part
of the GDP, so we should have whatever rights we need to allow people to
use the same title.  I think the GNOME Foundation has copyright
assignment forms now, so if we ask authors to fill out a form, we should
have no worries about keeping the same title between revisions/re-writes
of the manual.  Since we don't need to change the title of the work
every revision, and the version number is pretty clearly redundant
information, I don't think there's any reason to have it in the title.

Eric also stated that "GNOME" and "Manual" we redundant pieces of
information.  GNOME certainly seems to be redundant information, but XML
representation of that really needs some work before it's obvious. 
Here's what's in the gnome-calculator-C.omf file:
    <subject category="GNOME|Applications|Accessories"/>

While that works, I wonder what happened to moving that into a "proper
XML" way of doing things, with sub-elements, instead of having things
crammed into a single attribute separated by special characters?  I'm
sure there's a good argument for why doing things this way isn't good,
but I can't think of what it is.  :)

Looking at the OMF files that I have handy, and the original OMF
specification, it doesn't seem like "manual" is represented elsewhere in
the metadata.  This appears to be confirmed by the documentation on
"Writing Scrollkeeper OMF Files".  Since this information isn't
redundant at this point, I'd have to say that we should keep this
information as part of the title.  The list of valid elements for type
probably needs to be extended, as was discussed some time ago.  The
original list was suitable for the LDP, but isn't broad enough to cover
the expanding scope of OMF.

Please direct replies to the lists, I read both, so I'll take questions
and comments there.  Thanks,
	Greg

Re: [Scrollkeeper-devel] Packing scrollkeeper

[Dan M. <mu...@al...>]

On Tue, 16 Jul 2002, Brian Cameron wrote:

> Scrollkeeper experts:
> 
> I am currently working to make sure that Sun's shipment of
> scrollkeeper is correct.  I have a few questions that I need
> cleared up.
> 
> 1. I notice that scrollkeeper seems to have very similar files in
>    the following directories:
>    
>    share/scrollkeeper/Templates
>    var/lib/scrollkeeper
>    
>    Do we have to ship all the files in both directories?

The original data files are installed into the Templates path.  Whenever a 
new database is generated (ie. at first install time, or if the old 
database somehow gets corrupted and the admin decides to regenerate it) 
the files in Templates are copied into /var/... to initialize the database 
before any documents are registered.  

Note that the files under /var are variable (ie. they are generated and/or 
editted by running programs) while the other files installed by a package 
(eg. under /share or /usr/share or /bin ) are binaries or data files which 
should not be modified by running programs.

So, the short answer is that you should only install the files in 
Templates, and ScrollKeeper will generate the files under /var at the end 
of the installation process.

> 2. Sun packaging requires that the pkgmap specifies which files are
>    editable.  I understand some files that scrollkeeper installs can
>    be modified when future packages are installed.  Specifically
>    which files are installed?

None of the ScrollKeeper files (installed or generated) are intended to be 
modified by other packages.  Only /etc/scrollkeeper.conf should be editted 
by hand by an admin.  Scrollkeeper itself generates and modifies the files 
under /var, which is the database (/var/lib/scrollkeeper) along with the 
log files (/var/log/scrollkeeper*).  None of the files under /var get 
installed.  They are all generated by ScrollKeeper the first time it runs 
and then editted each time it runs.

> 3. Scrollkeeper ships with a bunch of executables in /bin.  Which of 
>    these need to be installed on an end-user system (because an
>    end-user would need to run them, or they get run in preinstall
>    or postinstall scripts).  
>    
> 4. Which /bin executables would only be used by a developer?  Which
>    ones only by a system administrator, and which (if any) by an end
>    user?  Would it make sense for programs run only by sysadmins
>    (like in preinstall & postinstall scripts) to be moved to /sbin?
>    
> For reference, here is a list of everything scrollkeeper ships in /bin:
> 

developers and anybody building a package from source:
>   /bin/scrollkeeper-preinstall

developers only:
>   /bin/scrollkeeper-gen-seriesid
>   /bin/scrollkeeper-extract

admins and end-users (ie. it may used when installing and uninstalling 
packages, so everybody needs these):
>   /bin/scrollkeeper-update
>   /bin/scrollkeeper-install
>   /bin/scrollkeeper-uninstall
>   /bin/scrollkeeper-rebuilddb

Users.  This is run by various other binaries to identify the location  
other ScrollKeeper files were installed.
>   /bin/scrollkeeper-config

Users.  These are run by a help browser to access the data:
>   /bin/scrollkeeper-get-cl
>   /bin/scrollkeeper-get-content-list
>   /bin/scrollkeeper-get-toc-from-id
>   /bin/scrollkeeper-get-toc-from-docpath
>   /bin/scrollkeeper-get-index-from-docpath
>   /bin/scrollkeeper-get-extended-content-list

I'm not sure which ones really belong in /sbin, if any.  Perhaps the 4 
starting with scrollkeeper-update and none of the others.

I hope this helps.

-Dan

[Scrollkeeper-devel] Packing scrollkeeper

[Brian C. <Bri...@su...>]

Scrollkeeper experts:

I am currently working to make sure that Sun's shipment of
scrollkeeper is correct.  I have a few questions that I need
cleared up.

1. I notice that scrollkeeper seems to have very similar files in
   the following directories:
   
   share/scrollkeeper/Templates
   var/lib/scrollkeeper
   
   Do we have to ship all the files in both directories?
   
2. Sun packaging requires that the pkgmap specifies which files are
   editable.  I understand some files that scrollkeeper installs can
   be modified when future packages are installed.  Specifically
   which files are installed?

3. Scrollkeeper ships with a bunch of executables in /bin.  Which of 
   these need to be installed on an end-user system (because an
   end-user would need to run them, or they get run in preinstall
   or postinstall scripts).  
   
4. Which /bin executables would only be used by a developer?  Which
   ones only by a system administrator, and which (if any) by an end
   user?  Would it make sense for programs run only by sysadmins
   (like in preinstall & postinstall scripts) to be moved to /sbin?
   
For reference, here is a list of everything scrollkeeper ships in /bin:

  /bin/scrollkeeper-preinstall
  /bin/scrollkeeper-update
  /bin/scrollkeeper-install
  /bin/scrollkeeper-uninstall
  /bin/scrollkeeper-get-cl
  /bin/scrollkeeper-extract
  /bin/scrollkeeper-gen-seriesid
  /bin/scrollkeeper-config
  /bin/scrollkeeper-get-content-list
  /bin/scrollkeeper-get-toc-from-id
  /bin/scrollkeeper-get-toc-from-docpath
  /bin/scrollkeeper-get-index-from-docpath
  /bin/scrollkeeper-get-extended-content-list
  /bin/scrollkeeper-rebuilddb

Thanks!

Brian

[Scrollkeeper-devel] Re: Shortened titles in OMFs and Yelp

[Eugene O'C. <eug...@su...>]

I think that the longer titles came about to comply with the GFDL. In the Modifications section, point A, it says:

"Use ... a title distinct ... from those of previous versions (which should, if there were any, be listed in the History section of the Document)."

Using the version number in the title is the simplest way to create a title distinct from previous versions.

The word Manual appears in the title so that people understand that the version number applies to the manual and not to the application or applet.

I think that the word GNOME appears as a hangover from when the word GNOME appeared in either the menu that started the application or applet, or the titlebar of the application window. As such, I agree that it is unnecessary and can be removed from the document title. However, Irene is much closer to this than I am, and I would like to check this with her.

To comply with the GFDL, I think that the document titles must contain the appname, the word Manual, and the version number. 

So, I do still think that we need to add some metadata to the OMF, that is, the shorttitle attribute in the title element.

And so I propose that we implement the shorttitle attribute, and in the meantime proceed with what Dan and I were discussing yesterday, that is:

<!--
    <title>
      GNOME Calculator Manual V2.0
    </title>
-->
    <title>
      Calculator
    </title>

Unlike the <comment> tag I suggested yesterday, this validates against the Scrollkeeper DTD.

Eric Baudais wrote:
> 
> With all that I'd like to propose that the GDP shorten the titles in the
> documentation which contain redundant information.  The information
> taken out of the titles should already be contained in either the
> metadata or the title page.  The title changes in the documentation
> should propagate to the OMF files and the titles in the <title> tag
> should be appropriately changed.
> 
> Eric Baudais
> 
> _______________________________________________
> gnome-doc-list mailing list
> gno...@gn...
> http://mail.gnome.org/mailman/listinfo/gnome-doc-list

[Scrollkeeper-devel] Re: Shortened titles in OMFs and Yelp

[Eric B. <ba...@kk...>]

I'd like to explain a little bit of the history and my reasoning in
rejecting this idea of either adding a second title or replacing the
title with a shorter version.

The GNOME documentation used to have somewhat short titles before GNOME
2.0.  The titles used to be like "Gedit."  This all changed for GNOME
2.  Why did it change?  I believe that the change came as a result of a
discussion about what types of information should be displayed on the
title page and what information should be displayed on the TOC page. 
There were recommendations for including the author, version,
maintainer, and title at the top of the TOC.  This was rejected by Pat. 
He said, "I'm not saying that the above information is not important, on
the contrary it is vital, but it is meta-information that is aimed at a
different audience than the user."  This vital metadata was put into a
separate title page which came about with contributions from everyone. 
This may not seem very important, but then the titles got bigger from
the examples in both the templates and the sample title page.  Character
Picker Applet Manual V0.2 became the title for the sample title page and
the templates produced MY-GNOME-APPLICATION Manual V2.0.  The titles
were making up for the loss of information in the first page the user
views (TOC page).  This has resulted in large titles which Yelp cannot
handle.  Is the solution to add some more metadata?

On Mon, 2002-07-15 at 12:28, Dan Mueth wrote:
> 
> On Mon, 15 Jul 2002, Eugene O'Connor wrote:
> 
> > So it's OK to use, for example: 
> > 
> >    <title>
> >      Calculator
> >    </title>
> > 
> > until the shorttitle attribute is implemented? 
> 
> Yes.

Yes, this is a very good idea.  The title of a document should be short,
sweet, and to the point.  This problem of cancerous titles which grow
and grow without bounds should be ended.  I would also suggest to make
the title of the Calculator documentation just "Calculator".  The
metadata should describe the type of documentation, the version, the
authors, and the license. Therefore there needs to be two changes made. 
The first change to the OMF file to shorten the title and the second
change to the documentation to alter the title to the shortened title
within the OMF file.

> > The contents of the OMF <title> tag do not have to match the contents of
> > the XML <title> tag? If that's the case, perhaps we can use the original
> > suggestion so that we can easily update the OMF files when the 
> > shorttitle attribute is implemented. The original suggestion was:
> > 
> >   <comment>
> >      GNOME Calculator Manual V2.0
> >    </comment>
> >    <title>
> >      Calculator
> >    </title>
> > 
> > What do you think?

I don't like this.  With the title of the documentation being
"Calculator" the comment tag is redundant.  It describes information
that is already in the metadata.

1) GNOME is in the category.  The category already classifies the
documentation and you don't need to repeat that classification.

2) Calculator is in the title.  It is the title of the documentation and
should not need to be restated here.

3) Manual is in the type.  The type metadata already describes the type
of documentation.  Again repeated information.

4) V2.0 is in the version.  The version metadata describes the version
of the document along with the date and a short description.  Also
repeated information.
 
> I like the idea of preserving the original title in the OMF file as a 
> comment so that the OMF files can be easily updated later.  However, 
> <comment> is not a valid OMF element.  So, an OMF file which looks like 
> the above will not validate and the document will not be registered with 
> ScrollKeeper :(

Scrollkeeper shouldn't have to break the OMF specification.  The
metadata should describe the document as fully as possible, but without
repeating or stating the information in another way.  I believe that the
OMF specification has done that and should not be changed at all.  Also
any changes should be questioned thoroughly as to there need.  A couple
questions should be asked when contemplating a change:

1) Does this tag describe new information not already in the other tags?

2) Does this tag information which is useful to all the documents?

With all that I'd like to propose that the GDP shorten the titles in the
documentation which contain redundant information.  The information
taken out of the titles should already be contained in either the
metadata or the title page.  The title changes in the documentation
should propagate to the OMF files and the titles in the <title> tag
should be appropriately changed.

Eric Baudais

[Scrollkeeper-devel] Re: Shortened titles in OMFs and Yelp

[Dan M. <mu...@al...>]

On Mon, 15 Jul 2002, Eugene O'Connor wrote:

> So it's OK to use, for example: 
> 
>    <title>
>      Calculator
>    </title>
> 
> until the shorttitle attribute is implemented? 

Yes.

> The contents of the OMF <title> tag do not have to match the contents of
> the XML <title> tag? If that's the case, perhaps we can use the original
> suggestion so that we can easily update the OMF files when the 
> shorttitle attribute is implemented. The original suggestion was:
> 
>   <comment>
>      GNOME Calculator Manual V2.0
>    </comment>
>    <title>
>      Calculator
>    </title>
> 
> What do you think?

I like the idea of preserving the original title in the OMF file as a 
comment so that the OMF files can be easily updated later.  However, 
<comment> is not a valid OMF element.  So, an OMF file which looks like 
the above will not validate and the document will not be registered with 
ScrollKeeper :(

We should use the standard XML comment:

<!--
    <title>
      GNOME Calculator Manual V2.0
    </title>
-->
    <title>
      Calculator
    </title>


-Dan

[Scrollkeeper-devel] Re: Shortened titles in OMFs and Yelp

[Eugene O'C. <eug...@su...>]

Dan Mueth wrote:
> 
> I like the idea of introducing an optional attribute to <title>, such as
> 'shorttitle', for people to include a briefer title.  We should come up
> with some guidelines for its use.  As a start:
> * For application manuals, typically just include the application title.
> (ie. omit articles like "The" and words like "Manual")
> * A short title should be no longer than ___ characters.  (How many?)
> * Do not include document or application version information

So the OMF file will look like this:

   <title shorttitle="Calculator">
     GNOME Calculator Manual V2.0
   </title>

Looks good to me.

The guidelines and definition look good. I wonder whether we should specify a precise number of characters though. Perhaps it would be better to leave some flexibility and say "usually less than 20 characters".  

> 
> Since existing versions of ScrollKeeper doesn't support the 'shorttitle'
> attribute, it seems reasonable for GNOME to use abbreviated titles in the
> title element for now (everybody gets to name their own documents, after
> all).

So it's OK to use, for example: 

   <title>
     Calculator
   </title>

until the shorttitle attribute is implemented? The contents of the OMF <title> tag do not have to match the contents of the XML <title> tag? If that's the case, perhaps we can use the original suggestion so that we can easily update the OMF files when the shorttitle attribute is implemented. The original suggestion was:

  <comment>
     GNOME Calculator Manual V2.0
   </comment>
   <title>
     Calculator
   </title>

What do you think?

> 
> Hopefully we can resolve this issue quickly and add the 'shorttitle'
> attribute very soon.  Any opinions on how (or whether) we should implement
> the 'shorttitle' attribute and on its use guidelines are welcome and
> encouraged.
>

[Scrollkeeper-devel] Re: Shortened titles in OMFs and Yelp

[Dan M. <mu...@al...>]

This thread has been maturing on gnome-doc-list, but I wanted to add my 
own comments and cross-post it on scrollkeeper-devel...

ScrollKeeper and the variant of the OMF which it is uses is meant to
enable help browsers to provide a nice interface to documentation they
have access to.  While I do not like the idea of moving the ScrollKeeper
varient of the OMF away from the official OMF (and I hope to bring them
into sync at some point), the direction of ScrollKeeper and its metadata
format must be driven by the needs of the end-users and the documentation
browsers they use.

All applications with a user interface have constraints on how much
information they can present at a given time.  For many GUI applications
space is limited and the full proper names of titles may not fit in the
available space (eg. in a display of the contents list showing all the
document categories and titles).  This is a problem with Yelp, but more
generally this will be a problem for many graphical help browsers.  If the
metadata also provides abreviated titles, better help browsers can be made
since titles can be made to more reasonably fit in the available space
(and in many cases will be more readable by the end-user).  (I do not
believe help browsers can intelligently abreviate titles, or that they
should have to.)

I like the idea of introducing an optional attribute to <title>, such as
'shorttitle', for people to include a briefer title.  We should come up
with some guidelines for its use.  As a start: 
* For application manuals, typically just include the application title.  
(ie. omit articles like "The" and words like "Manual")
* A short title should be no longer than ___ characters.  (How many?) 
* Do not include document or application version information

As a definition, we can start with something like: "'shorttitle' is a 
short form (less than ____ characters) of the document title which may 
optionally be used by document browsers where longer, full titles may not 
fit in the available space."

Since existing versions of ScrollKeeper doesn't support the 'shorttitle'
attribute, it seems reasonable for GNOME to use abbreviated titles in the
title element for now (everybody gets to name their own documents, after
all).  

Hopefully we can resolve this issue quickly and add the 'shorttitle'
attribute very soon.  Any opinions on how (or whether) we should implement
the 'shorttitle' attribute and on its use guidelines are welcome and
encouraged.

-Dan

Re: [Scrollkeeper-devel] Please help with this installation problem

[Dan M. <mu...@al...>]

Hi Scott,

The xmlcatalog binary is part of libxml2.  The scripts in the DocBook DTD
package on the ScrollKeeper web page assume that xmlcatalog is installed
in /usr/bin.  (These scripts are adapted from versions in libxml2.)  Do
you have libxml2 and xmlcatalog?  Is xmlcatalog in /usr/bin?

If it is installed somewhere else, you might want to create a symbolic 
link from /usr/bin/xmlcatalog to it.

Dan


On Tue, 9 Jul 2002, Scott S. Jones D.C. wrote:

> I run 'make install' per the instructions to install DocBook. 
> 
> Here's the result from my attempt.
> 
> install ent/* /usr/share/xml/docbook/xml-dtd-4.1.2-9/ent	
> #
> # XML Catalog
> #
> # DocBook XML V4.1.2
> creating XML Catalog root /etc/xml/catalog
> ./buildDocBookCatalog: /usr/bin/xmlcatalog: No such file or directory
> Failed creating XML Catalog root /etc/xml/catalog
> make: *** [register-catalog] Error 1				
> 
> 
> Please advise as to how I can get the catalogs to be created correctly and 
> thus allow the rest of the installing to run well.
> 
> Thank You,
> 
> Scott Jones
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Stuff, things, and much much more.
> http://thinkgeek.com/sf
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> https://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel
> 

[Scrollkeeper-devel] Please help with this installation problem

[Scott S. J. D.C. <dr...@vi...>]

I run 'make install' per the instructions to install DocBook. 

Here's the result from my attempt.

install ent/* /usr/share/xml/docbook/xml-dtd-4.1.2-9/ent	
#
# XML Catalog
#
# DocBook XML V4.1.2
creating XML Catalog root /etc/xml/catalog
./buildDocBookCatalog: /usr/bin/xmlcatalog: No such file or directory
Failed creating XML Catalog root /etc/xml/catalog
make: *** [register-catalog] Error 1				


Please advise as to how I can get the catalogs to be created correctly and 
thus allow the rest of the installing to run well.

Thank You,

Scott Jones

[Scrollkeeper-devel] test 347

[Scott S. J. D.C. <dr...@vi...>]

Anyone on the list receiving my email? 

No reply needed just testing.

[Scrollkeeper-devel] Trouble installing Scrollkeeper

[Scott S. J. D.C. <dr...@vi...>]

Dear List:

Here's what I get when I go to my /docbookx412 folder, running make install:

[root@scott docbookx412]# make install
mkdir -p /usr/share/xml/docbook/xml-dtd-4.1.2-9/ent
chown -R root.root .
chmod -R a+rX,g-w,o-w .
install docbook.cat /usr/share/xml/docbook/xml-dtd-4.1.2-9/catalog
install *.dtd /usr/share/xml/docbook/xml-dtd-4.1.2-9
install *.mod /usr/share/xml/docbook/xml-dtd-4.1.2-9
install ent/* /usr/share/xml/docbook/xml-dtd-4.1.2-9/ent
#
# XML Catalog
#
# DocBook XML V4.1.2
creating XML Catalog root /etc/xml/catalog
./buildDocBookCatalog: /usr/bin/xmlcatalog: No such file or directory
Failed creating XML Catalog root /etc/xml/catalog
make: *** [register-catalog] Error 1

And here is the output when running ./configure in my /scrollkeeper-0.3.9 
folder: 

checking libxml2 version... 2.4.22
checking for xslt-config... /usr/local/bin/xslt-config
checking for docbook-dtd412-xml... * ERROR *
 
Couldn't find the DocBook XML V4.1.2 DTD.  Please make sure that you have the 
docbook-dtd412-xml package installed. If it is installed, the package 
probably did not register the DTD in the catalog properly. Consult 
http://scrollkeeper.sourceforge.net/docbook.shtml for more information.
 
configure: error: DocBook XML V4.1.2 DTD not present in /etc/xml/catalog. 
Make sure docbook-dtd412-xml is installed and registers DTD in catalog.
[root@scott scrollkeeper-0.3.9]#

This occurs whether i am logged in as my user name or as root. 

My question is how do I go about helping docbook to properly install the 
catalogs that it needs to function correctly? 

Thank You,

Scott
dr...@vi...

Re: [Scrollkeeper-devel] failure on ./configure run

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

On Sat, 2002-06-29 at 08:24, Scott S. Jones D.C. wrote:
> Dear listers: 
> 
> I am experiencing some difficulty installing ScrollKeeper in my larger 
> attempt to install Gnome. The last command information while running 
> ./configure follows: 
> 
> checking for xslt-config... /usr/local/bin/xslt-config
> checking for docbook-dtd412-xml... * ERROR *
>  
> Couldn't find the DocBook XML V4.1.2 DTD.  Please make sure that you have the 
> docbook-dtd412-xml package installed. If it is installed, the package 
> probably did not register the DTD in the catalog properly. Consult 
> http://scrollkeeper.sourceforge.net/docbook.shtml for more information.
>  
> configure: error: DocBook XML V4.1.2 DTD not present in /etc/xml/catalog. 
> Make sure docbook-dtd412-xml is installed and registers DTD in catalog.
> [scott@scott scrollkeeper-0.3.9]$
> 
> It appears to me that I have problems with the 'catalog'. Being new to this 
> particular application I am not sure what or where the 'catalog' is, resides 
> or should reside on my system. 
> 

Scott -

Have you followed the instructions on the web page mentioned? The error
here is that the DocBook DTD is not installed and/or not properly
registered with your computer's XML catalog, which is a file that keeps
track of the location of local copies of XML DTD files.

The solution is to install the version of the DTD mentioned on the SK
web page. Do that first, if you've already done that and it still
doesn't work, then we'll proceed to the next step of debugging your
problem.

Cheers,

John
-- 
John Fleck
jf...@in... (h) jf...@ab... (w)
http://www.inkstain.net http://www.abqjournal.com

"Sometimes, a diner is all about the mac and cheese." 
  - Zippy the Pinhead

[Scrollkeeper-devel] failure on ./configure run

[Scott S. J. D.C. <dr...@vi...>]

Dear listers: 

I am experiencing some difficulty installing ScrollKeeper in my larger 
attempt to install Gnome. The last command information while running 
./configure follows: 

checking for xslt-config... /usr/local/bin/xslt-config
checking for docbook-dtd412-xml... * ERROR *
 
Couldn't find the DocBook XML V4.1.2 DTD.  Please make sure that you have the 
docbook-dtd412-xml package installed. If it is installed, the package 
probably did not register the DTD in the catalog properly. Consult 
http://scrollkeeper.sourceforge.net/docbook.shtml for more information.
 
configure: error: DocBook XML V4.1.2 DTD not present in /etc/xml/catalog. 
Make sure docbook-dtd412-xml is installed and registers DTD in catalog.
[scott@scott scrollkeeper-0.3.9]$

It appears to me that I have problems with the 'catalog'. Being new to this 
particular application I am not sure what or where the 'catalog' is, resides 
or should reside on my system. 

Please help me resolve this. 

Thank You,

Scott

[Scrollkeeper-devel] The locale given to scrollkeeper-get-content-list

[Mikael H. <mi...@co...>]

Hi!

Looks like the problem with #73497 (gnome bugzilla) is that if I give it
locale 'sv_SE.ISO-8859-1' it looks for that and 'sv_SE' but not for
'sv'.

So, what is the correct way, do I need to extract the 'sv' from
'sv_SE.ISO-8859-1' or should this be handled by scrollkeeper?

Regards,
  Mikael Hallendal

-- 
Mikael Hallendal                mi...@co...
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918

[Scrollkeeper-devel] SunOS 5.8 Build problems

[John G. <jg...@le...>]

Here are the details of what I have done and what is failing.

I have 
unsetenv MAKE
unsetenv LD_LIBRARY_PATH
setenv XML_CONFIG /i/btools/sparc-SunOS-5.8/libxml2-2.4.22/bin/xml2-config
setenv XML_CONFIG /i/btools/sparc-SunOS-5.8/libxslt-1.0.18/bin/xslt-config
setenv INTLTOOL /i/btools/sparc-SunOS-5.8/intltool-0.22/bin/intltool-extract
setenv INTLTOOL_PERL /i/btools/sparc-SunOS-5.8/perl-5.005_03/bin/perl
setenv XGETTEXT /i/btools/sparc-SunOS-5.8/gettext-0.10.35/bin/xgettext
setenv PERL /i/btools/sparc-SunOS-5.8/perl-5.005_03/bin/perl
setenv CC /i/btools/sparc-SunOS-5.8/gcc-2.95.2/bin/gcc

umask 022

configure --prefix=/i/btools/sparc-SunOS-5.8/scrollkeeper-0.3.10 --enable-rpath  --without-included-gettext

make


Here is the ERROR I get
make[3]: Leaving directory `/i/btools/sparc-SunOS-5.8/src/scrollkeeper-0.3.10/man'
make[2]: Leaving directory `/i/btools/sparc-SunOS-5.8/src/scrollkeeper-0.3.10/man'
Making all in intl
make[2]: Entering directory `/i/btools/sparc-SunOS-5.8/src/scrollkeeper-0.3.10/intl'
make[2]: *** No rule to make target `libintl.@l@a', needed by `all-yes'.  Stop.
make[2]: Leaving directory `/i/btools/sparc-SunOS-5.8/src/scrollkeeper-0.3.10/intl'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/i/btools/sparc-SunOS-5.8/src/scrollkeeper-0.3.10'
make: *** [all-recursive-am] Error 2
[aug-lib@monoceros]<>/i/btools/sparc-SunOS-5.8/src/scrollkeeper-0.3.10/:


I have tried not setting the --without-included-gettext, and setting
--with-included-gettext, and setting 
--with-included-gettext=/i/btools/sparc-SunOS-5.8/gettext-0.10.35/lib
Nothing seems to get past this error.

I am attaching the intl/Makefile and my config.status in hopes that  will
help. In the intl/Makefile you have l = @l@ which looks very weird (like maybe
a  configure substitution went wrong) because you use $l every where you turn
around in the intl/Makefile. Thanks in advance for any help/ light you shed on
this problem.

-- 
John Gibson jg...@le...
Pinky, are you pondering what I am pondering?
I think so Brain, but why does a forklift have to be so big if all it
does is lift forks?

Re: [Scrollkeeper-devel] Re: ScrollKeeper 0.3.10 Released

[Dan M. <mu...@al...>]

On Thu, 20 Jun 2002, Sander Vesik wrote:

> On Fri, 21 Jun 2002, Jeff Waugh wrote:
> 
> > <quote who="Dan Mueth">
> > 
> > > ScrollKeeper 0.3.10 is now available.
> > 
> > Should this ship with GNOME 2.0.0?
> > 
> 
> AFAIK, very probably yes.

The only things that have been going into 0.3.x lately are bug fixes, and
typically very minor patches at that.  So, we should be pretty safe
shipping the latest 0.3.x release.

-Dan