Please find below a script that I have created to transform the .xml files from the
pekwm documentation into plain text files. The result is available here. The
starting .xml material is in the doc directory of the pekwm source at github under
pekdon/pekwm.

I spent a couple of hours combing the Web, but could not find no satisfactory utility.
Most required python; some others, to dish out a lot of cash... I did find a nice little
java applet in German, but it converts from xml to csv, which was not ideal.

Puppies do have the xmllint utility. It does a fair job of converting xml to html but
loses any paragraph structure. (A fine utility that is...) It was ok with the smaller
xml files in the pekwm docs, but not for the larger ones. This is the moment when
you realize that you are lost without the blank line separator!!!

So I took the bull by the horns, and decided to convert the pekwm docs to text
format using the replaceit utility and a couple of GNU standards.

This is the script. I know there are as many xml styles as there are stars in the
sky, but It may be useful to someone as a starting point.

It's still in crude form, I'm afraid. Any improvements and/or constructive
observations will be welcome.

BFN.

~~~~~~~~~~~~~~

Code:

#!/bin/sh
# /opt/local/bin/xml2txt.sh
# (c) musher0, 12 février 2018. GPL3
#
# Usage: enter a directory where there are xml files and
# issue the command < xml2txt.sh > (without the chevrons).
#
# All the xml files will be grouped in a text file
# bearing the name of the directory, and processed.
#
# Requires : replaceit.
#
# Comment: it leaves to be desired, you will have to refine
# the output; but it does a basic job of eliminating most (?)
# of the XML tags.
#
####
name="`pwd | awk -F"/" '{ print $NF }'`"

It's always the same thing with these apps that pretend to convert from xml:
you need the style sheet for the xml file, and as I said, there are as many of
those as there are stars in the sky.

Of course the author of the original xml file seldom provides said style sheet. And
to really complicate the problem, some xml authors do not know their xml, they
create xml files with errors in them! Can you believe that? How is a simple non-xml
bloke like me supposed to react?

In short, any xml file sends me up the well-known creek without a paddle.

~~~~~~~~~~~~

Reading some of the unix and/or linux forums, I saw that some of those guys use
common tools like sed, grep or awk to make xml files readable by humans.

One of them remarked that xml works with <tag> and <\untag>. Get it?

So in theory, you could come up with a script that scans the xml file for such tags,
notes what they are supposed to do, makes a little database of them, feeds them
to replaceit, maybe you have to use tr or awk or a similar utility to polish the
result, and voilà, now we would have a true text file readable by humans. Phew.

I hate xml. It was probably invented by some schizophrenic. No person with a sane
mind would have come up with such a contraption. IMO, xml is THE prime
example of: "why do simple when you can do complicated."

I think it's time to go to the pub with my good buddy Will Ockham, and send some
simple Belgian white down our gullets.

¤ Decor (string) ¤
Use the specified decor for this window. The decor has to be
defined in the used theme. The decor is chosen by the first
match in order: AutoProperty, TypeRules, DecorRules.

¤ Focusable (bool) ¤
Toggles if this client can be focused while it's running.

¤ FocusNew (bool) ¤
Toggles if this client gets focused when it initially pops up
a window.

¤ FrameGeometry (geom) ¤
X Geometry String showing the initial size and position of
the window frame. Window frame includes the client window
and the possible pekwm titlebar and window borders. If both
ClientGeometry and FrameGeometry are present, FrameGeometry
overrides the ClientGeometry.

¤ Fullscreen (bool) ¤ Window starts in fullscreen mode

¤ Group (string) ¤
Defines the name of the group. Also the section that contains all
the grouping options. They are:

Behind (bool) - If true makes new clients of a group not to
become the active one in the group.

FocusedFirst (bool) - If true and there are more than one frame
where the window could be autogrouped into, the currently
focused frame is considered the first option.

Global (bool) - If true makes new clients start in a group even
if the group is on another workspace or iconified.

Raise (bool) - If true makes new clients raise the frame they
open in.

Size (integer) - How many clients should be grouped in one group.

¤ Iconified (bool) ¤ Window starts Iconified

¤ Layer (string) ¤ Windows layer.
Makes the window stay under or above other windows. Default layer
is "Normal". Possible parameters are (listed from the bottommost to
the uppermost):

¤ MaximizedHorizontal (bool) ¤
Window starts Maximized Horizontally

¤ MaximizedVertical (bool) ¤
Window starts Maximized Vertically

¤ Opacity (int int) ¤
Sets the focused and unfocused opacity values for the window. A value of
100 means completely opaque, while 0 stands for completely transparent.
Note that a Composite Manager needs to be running for this feature to
take effect.

¤ PlaceNew (bool) ¤
Toggles the use of placing rules for this client.

¤ Role (string) ¤
Apply this autoproperty on clients that have a WM_WINDOW_ROLE hint that
matches this string. String is a regexp like: "^Main".

¤ Shaded (bool) ¤
Window starts Shaded

¤ Skip (string) ¤
A list of situations when to ignore the defined application and let the user action
skip over it, consisting of

"Snap" (Do not snap to this window while moving windows)

"Menus" (Do not show this window in pekwm menus other than the icon menu)

"FocusToggle" (Do not focus to this window when doing Next/PrevFrame)

¤ Sticky (bool) ¤
Window starts Sticky (present on all workspaces)

¤ Title (string) ¤
Apply this autoproperty on clients that have a title that matches this string. String is
a regexp like: "^Saving".

<para>
Below is a list of the different actions available to you in your
autoproperties file; These are the actual Auto Properties. They
can take four types of arguments: bool, integer, string, or geom.
A bool is either True (1) or False (0). An Integer is a number,
negative or positive. A string is any string, it's used as an
identifier. Finally, geom is an X Geometry String by the form:
"[=][&lt;width&gt;{xX}&lt;height&gt;][{+-}&lt;xoffset&gt;{+-}&lt;yoffset&gt;]"
(see: man 3 XParseGeometry). Examples are 200x300+0+0,
0x500+200+300, 20x10+0+50, et cetera.
</para>

A most eloquent example of "why do simple when you can do complicated! (IMO)
I mention it again, because you have to think of the time it took the author to layout the initial text file (there had to be
one, no?) in xml. And then only a specialized program can read it. Ha! _________________musher0
~~~~~~~~~~
"Logical entities must not be multiplied beyond necessity." | |
« Il ne faut pas multiplier les entités logiques sans nécessité. » (Ockham)

I wouldn't think that "single-source publishing" is a reason for not including a css file
along with a xml document. On the contrary, if I were the editor, I would strive to
make available multiple css files (or similar), one for each media.

In any case, I find this ciriticism of it interesting. (From the wikipeda article.)

Quote:

Criticism
Editors using single-source publishing have been criticized for below-standard work
quality, leading some critics to describe single-source publishing as the "conveyor
belt assembly" of content creation.[15]

While heavily used in technical translation, there are risks of error in regard to
indexing. While two words might be synonyms in English, they may not be
synonyms in another language. In a document produced via single-sourcing, the
index will be translated automatically and the two words will be rendered as
synonyms. This is because they are synonyms in the source language, while in the
target language they are not.

On the contrary, if I were the editor, I would strive to
make available multiple css files (or similar), one for each media.

This would make sense for similarly structured HTML/XHTML documents. Here the authors almost always provide CSS files because they want to make sure that a page is rendered exactly the way they designed it and not in the way the browser renders page elements by default.
Less common is to provide CSS files for specific media. Apart from the extra work involved authors can't be sure that browsers can handle media dependent CSS.

DocBooks are a bit different. As puppy_apprentice already indicated, DocBooks are meant to be transformed to other formats like HTML, PDF, man pages or whatever (not sure though if 'whatever' includes TXT). This is done by XLS stylesheets and those stylesheets are already developed and are maintained by the DocBook community at Sourceforge, so there is really no need for DocBook authors to develop or supply them with their XML documents.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum