[new XSL] The Index generation
Hi,
The generation of the Index is one of the most broken parts using the new
DocBook-XSL code. That meant that that higly customized stylesheets need be
full reworked.
Due that it need be reworked in any case, I would take advantage of a new
available feature: The possibility to create separate index pages for each
index section. That is, an index HTML page for packages, another for
programs, another for libraries, and so on.
To acomplish that (if I can implement it) a few changes will be need on how
{indexterm} block are tagged. For example, at a first look and waiting for
testing, a current entry like:
{indexterm zone=ch-system-bash}
{primary sortas=a-Bash}Bash{/primary}
{/indexterm}
could be
{indexterm zone=ch-system-bash type=package}
{primary}Bash{/primary}
{/indexterm}
I.e, the sortas attribute in {primary} will be replaced by a type
attribute in {indexterm}.
Of course, that XML changes can't be made until have the new XSL code ready.
Thus the question is, do you want that I start working on that Index pages
split or do you want only to fix the current very long longindex.xtml page
generation?
I could try to prepare a very simple POC of that index pages split if you need
something to look-at before taking a decission.
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info
TLDP-ES: http://es.tldp.org
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [new XSL] The Index generation
Randy McMurchy wrote: I'm sitting on the fence here. On one hand, I like the idea of individual indexes for packages/libraries/programs/etc. because of the reduced sizes and faster loading times. But on the other hand I don't want to have to open up multiple indexes to find what I'm looking for. Why not both? Those who know their way around can look at the individual indexes but there's always the long index for those who want it. Have them link to eachother. Just my $0.02. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [new XSL] The Index generation
Joe Ciccone wrote these words on 03/26/07 17:02 CST: Why not both? Those who know their way around can look at the individual indexes but there's always the long index for those who want it. Have them link to eachother. Just my $0.02. Good thought. But it is a helluva lot of work for Manuel, for what I consider very little gain. -- Randy rmlscsi: [bogomips 1003.28] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 17:13:00 up 17 days, 15:12, 1 user, load average: 0.12, 0.03, 0.01 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [new XSL] The Index generation
Randy McMurchy wrote: Joe Ciccone wrote these words on 03/26/07 17:02 CST: Why not both? Those who know their way around can look at the individual indexes but there's always the long index for those who want it. Have them link to eachother. Just my $0.02. Good thought. But it is a helluva lot of work for Manuel, for what I consider very little gain. I agree that the gain is small. The book is over 1000 pages now. I'd rather see some new sections. See http://wiki.linuxfromscratch.org/blfs/query?status=newstatus=assignedstatus=reopenedgroup=milestonemilestone=futuretype=enhancementorder=priority Although this has been a reasonable discussion, I don't think it should be implemented. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
