Re: DOCBOOK-APPS: Best Practices
I have been forced (yes, sounds strange) to implement some solution(s) to allow people in the company write documents that could be easily (?) translated to XML. Well, due to the lack of time I had to make it run, and being unable in this short time to discover if I would be capable of customizing some programs like Frame Maker, I took the quick approach and choose Word, which is the text processor all in my company use. Although there is a long way before we reach the items you mentioned, I have concluded that the task can be done (even with Word). I would happily participate in any forum/work dedicated to this question, surely much more to learn than to contribute ;-) Best regards, Juan R. Migoya SPAIN
RE: DOCBOOK-APPS: Best Practices
-Original Message- From: Juan R. Migoya [mailto:[EMAIL PROTECTED] I have been forced (yes, sounds strange) to implement some solution(s) to allow people in the company write documents that could be easily (?) translated to XML. Well, due to the lack of time I had to make it run, and being unable in this short time to discover if I would be capable of customizing some programs like Frame Maker, I took the quick approach and choose Word, which is the text processor all in my company use. Although there is a long way before we reach the items you mentioned, I have concluded that the task can be done (even with Word). I would happily participate in any forum/work dedicated to this question, surely much more to learn than to contribute ;-) Juan, Thanks for the offer of support. Word is certainly a tool under consideration, especially since MS intends to include XML Support with the new Office. However, it is not the only solution and the tool chain extends beyond just the editing environment. Personally I don't mind which editor people use, so long as it is productive and conforms to open standards and hence has no lock in to proprietary formats. Unfortunately MS does not have a very good track record when it comes to standards compliance. I hope they will stay in compliance with W3C with the new Office. Certainly, many users can only use Word and are not technical enough to learn another tool. Using an existing tool like Word, in parts or the organization, will dramatically reduce implementation costs. Especially in the areas of licensing and training. More technical departments/users may use more specialized editors or even emacs + psgmls. Can you imagine asking the reception to use emacs? Perhaps you can lend us your requirements and reasoning for concluding that the task can be done (even with Word). This, together with other contributions can be a starting point for further discussion/debate within the community. Regards, Sean Wheller
DOCBOOK-APPS: how to terminate XML tags in emacs
as a final efficiency for typing in my XML, i'd like to add an emacs function to auto-terminate tags, as one can do in emacs+psgml. (i don't know enough about psgml to see how it does it, but i don't need all of psgml -- just this one feature.) all i want to be able to do is, with a control sequence (from psgml, what was it? C-c / or just C-/), be able to close the innermost element, that's all. i don't even care if it validates the element first, i just want to add a function that looks backwards for the last blah and adds /blah at that point, regardless of what blah actually says. can anyone just supply a function to do that that i can add to my .emacs file? rday
DOCBOOK-APPS: Re: FOP: boomarks don't work well
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Tobias Reif [EMAIL PROTECTED] was heard to say: | Can you also offer a fix for | http://lists.oasis-open.org/archives/docbook-apps/200302/msg00056.html | ? Other FO2PDF converters displayed the list. I thought I'd fixed that recently. Does it work with the latest? Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | If you run after wit you will http://www.oasis-open.org/docbook/ | succeed in catching Chair, DocBook Technical Committee | folly.--Montesquieu -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+WQxpOyltUcwYWjsRAlBiAJ9/yt7TUw8ebmO6+0NwLHaYfJDzdACggmDv 3/3guQEkMxfb42cU/Vf6PMs= =EDrY -END PGP SIGNATURE-
DOCBOOK-APPS: Re: FOP: boomarks don't work well
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/ Tobias Reif [EMAIL PROTECTED] was heard to say:
| Marko Petersen wrote:
|
| Same for me, I fixed that the following way:
| In glossary/component/division/index.xsl and so on, search for
| titlepage. And if you find something like
| fo:flow flow-name=xsl-region-body
| xsl:call-template name=dedication.titlepage/
| /fo:flow
| add a fo:block with the id to reference:
| fo:flow flow-name=xsl-region-body
| fo:block id={$id}
| xsl:call-template name=dedication.titlepage/
| /fo:block
| /fo:flow
| And not only for dedication, for every component you need...
|
| Thanks a lot for the tip.
|
| Instead of editing the NW-DBK2FO-XSLTs themselves, I'd override the
| relevant templates by copying them to my customization layer and
| editing them there.
|
| Bob or Norm:
|
| Or is it something that could be turned on with
|s:param name=fop.extensions select=1/
| ?
Didn't I fix this recently? I thought I did, but I have been on vacation :-)
Be seeing you,
norm
- --
Norman Walsh [EMAIL PROTECTED] | It is a general error to imagine
http://www.oasis-open.org/docbook/ | the loudest complainers for the
Chair, DocBook Technical Committee | public to be the most anxious for
| its welfare.--Edmund Burke, 1769
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/
iD8DBQE+WQ0UOyltUcwYWjsRAtFvAKCrSyu7kck4MubIZyT6OfCo0Km4YQCfVwQh
t+G9C6+YBY8O2C/TyRHbZZA=
=g7Yq
-END PGP SIGNATURE-
DOCBOOK-APPS: Re: What's the most appropriate (and futureproof) way tostyle the FO?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Bob Stayton [EMAIL PROTECTED] was heard to say: | Is the purpose of the titlepage mechanism to supersede and obsolete the | property set option params, or are both mechansims intended to be combined? | | Norm might want to answer this too, but | I believe the mechanisms are meant to be combined, in | a hierarchical manner. The titlepage.templates | mechanism establishes the default values, and the | propery attribute-sets provide the runtime flexibility. Right. | I can't say how 'futureproof these various mechanisms are. | It kind of seems like there are too many places | to set properties, but I believe some of that is the result of | stylesheet evolution, rather than by design. | So perhaps these will be consolidated a bit in the future. Yes, I think a little bit of conscious redesign is in order. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Be indiscrete. Do it continuously. http://www.oasis-open.org/docbook/ | Chair, DocBook Technical Committee | -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+WQ38OyltUcwYWjsRAsvbAJ0WkLSmyF+FqQP12KoCCoUO4waWdwCdFZM4 KCVjGNyccC0jlMa6MDUdW6U= =O+LI -END PGP SIGNATURE-
DOCBOOK-APPS: section titles as links, turning off in non-html output
I may have painted myself into a corner while trying to create some (hopefully) intuitive navigation functionality in a sdocbook article I'm working on. I've added a ULINK element to the TITLE for SECTION. Of course it works as expected and like a charm when I'm generating my html output. But, in multipurposing mode, I've just pumped out an RTF version of some of my document using the DSSSL stylesheets. I find that the link targets are enclosed in brackets after the TITLE text. This is confusing for the reader. Questions: * Being almost totally ignorant of the DSSSL side of the stylesheets, is there a handy parameter that might allow me to defeat this functionalisty. * Will I run into similar issues with link-enabled titles with, say, the FO output on the XSLT side? If so, is there an easy solution? Thanks for your help. ...edN
Re: DOCBOOK-APPS: section titles as links,turning off in non-html output
On Monday 24 February 2003 03:37, ed nixon wrote: I may have painted myself into a corner while trying to create some (hopefully) intuitive navigation functionality in a sdocbook article I'm working on. I've added a ULINK element to the TITLE for SECTION. Of course it works as expected and like a charm when I'm generating my html output. But, in multipurposing mode, I've just pumped out an RTF version of some of my document using the DSSSL stylesheets. I find that the link targets are enclosed in brackets after the TITLE text. This is confusing for the reader. Questions: * Being almost totally ignorant of the DSSSL side of the stylesheets, is there a handy parameter that might allow me to defeat this functionalisty. under debian with the docbook dsssl stylesheets 1.77 the file /usr/share/sgml/docbook/stylesheet/dsssl/modular/print/dbparam.dsl contains the following: (define %show-ulinks% ;; REFENTRY show-ulinks ;; PURP Display URLs after ULinks? ;; DESC ;; If true, the URL of each ULink will appear in parenthesis after ;; the text of the link. If the text of the link and the URL are ;; identical, the parenthetical URL is suppressed. ;; /DESC ;; AUTHOR N/A ;; /REFENTRY #t) you can override with the following in your dsssl customization. (define %show-ulinks% #f) Unfortunately that will probably switch ulinks off everywhere, and not just in your titles. In your customization you can probably redefine the entire element ulink .. definition in modular/print/dblink.dsl to change the following from: (if %show-ulinks% (make sequence (literal () (literal (attribute-string (normalize url))) (literal ))) (empty-sosofo))) to do something along the lines of (if (and %show-ulinks% (not (have-ancestor (normalize title (make sequence (literal () (literal (attribute-string (normalize url))) (literal ))) (empty-sosofo))) but I am just guessing :-) good luck Doug
