Hello, On Sep 7 17:20 Karl Eichwalder wrote (shortened):

Johannes Meixner writes:

...

If at least empty lines (i.e character sequences like \n\n) would be recognized as separators which result at least a line break, it would probably look better.

I think it used to work that way in the past. At least, it was possible to pre-format the texts in the PDB somehow and it got properly exported from the PDB suitable for yast and (in the very past) for the package list on the Web.

For current products the PDB is no longer used at all so that any kind of special pre-format is no longer available. Therefore YaST (or whatever tool which shows RPM description texts) must be prepared to display plain text descriptions correctly. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On 9/8/2010 at 06:31 PM, Karl Eichwalder wrote:

Johannes Meixner writes:

...

...

I think it used to work that way in the past. At least, it was possible to pre-format the texts in the PDB somehow and it got properly exported from the PDB suitable for yast and (in the very past) for the package list on the Web.

For current products the PDB is no longer used at all so that any kind of special pre-format is no longer available.

Therefore YaST (or whatever tool which shows RPM description texts) must be prepared to display plain text descriptions correctly.

Yes, that's the problem. Is this format ("plain text") described somewhere? As you said previously, yast probably honors two \n on a row as a paragraph separator.

# rpm -q --qf '%{DESCRIPTION}' $PACKAGE | sed \ -e 's/\&/\&/g' \ -e 's//\>/g' | awk \ 'BEGIN { print "<pre>" } { print } END { print "</pre>" }' ;-) Seriously, yeah, plain text is notoriously difficult to interpret... Tim -- Tim Serong Senior Clustering Engineer, OPS Engineering, Novell Inc. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Johannes Meixner writes:

On Sep 8 04:42 Tim Serong wrote (shortened):

...

# rpm -q --qf '%{DESCRIPTION}' $PACKAGE | sed \ -e 's/\&/\&/g' \ -e 's//\>/g' | awk \ 'BEGIN { print "<pre>" } { print } END { print "</pre>" }'

Thanks, but <pre> is a no-op. These days, various PDAs with small displays are in use, and then, there is this ncurses yast interface...

I suggest to insert a "fold -s -w 80" before the "sed" to break possibly too long lines in the RPM description... ;-)

"80" is too long for ncurses-yast running inside a default xterm. -- Karl Eichwalder R&D / Documentation SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On 9/9/2010 at 09:43 PM, Karl Eichwalder wrote:

Karl Eichwalder writes:

...

Johannes Meixner writes:

...

On Sep 8 04:42 Tim Serong wrote (shortened):

...

# rpm -q --qf '%{DESCRIPTION}' $PACKAGE | sed \ -e 's/\&/\&/g' \ -e 's//\>/g' | awk \ 'BEGIN { print "<pre>" } { print } END { print "</pre>" }'

Thanks, but <pre> is a no-op. These days, various PDAs with small displays are in use, and then, there is this ncurses yast interface...

BTW, the BS is also one of these "players" and it keeps line-breaks, but uses a proportional font... For example, see https://build.opensuse.org/package/binary?arch=i586&filename=opensuse-manuals_ en-11.3-31.1.noarch.rpm&package=opensuse-manuals_en&project=Documentation&repositor y=openSUSE_11.3

This is why formatted text without self-explaining markup sucks.

Yeah. You could probably get incredibly close to generally acceptable in most cases with parsing rules like: 0) In general, assume there is an intent to produce paragraphs of text (<p> if you're displaying with HTML). 1) Double linebreaks are paragraph markers, unless appearing between list items per rules 3-7. 2) Single linebreaks are replaced with spaces, again unless appearing between list items per rules 3-7. 3) Any line starting with '*', '-', 'o', '+' followed by a space is a bulleted list item. Any leading space before the list marker is the list indent, provided there is a previous list item with a smaller (or zero) indent. 4) Any lines immediately following a list item are a continuation of that list item if they have leading whitespace. 5) If, after applying rules 3 and 4, there is only one list item (following lines are regular text or EOF), then it's not really a list item and should be treated instead as a paragraph (think: notes down the bottom of some text, marked with '*'). 6) Any lines starting with '[0-9]+\.?' followed by a space are numeric list items, for which rules 3-5 apply the same as they do for bulleted lists. 7) After a single line which matches the case-insensitive regex '^\s*Authors:?\s*$', each line with leading whitespace is a bulleted list item. 8) Anything that looks like an email address or URL (per suitable regexes) is to be treated as an email address or URL as appropriate. But I guarantee there will still be plain text that the above rules will mis-display in some annoying fashion. And if you change the rules to fix those, it'll break others. Regards, Tim -- Tim Serong Senior Clustering Engineer, OPS Engineering, Novell Inc. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org