Yes, I was concerned about the complexity of the transformation. The tip
to give the complete listing of font-size of 1.08em and a smaller
font-size for all nested tags is the final solution I'm going to use.
It's much easier to understand and to implement. Thanks!
I don't work day-to-day with css, so these obvious and easier solutions
are _not_ obvious for me. That's why my ideas tend to be far more
complex than necessary. Thanks again!
On 6/9/2010 12:22 PM, P T Withington wrote:
As I said, I approve your change. You asked for alternatives, so I gave one.
I assume you were concerned about the complexity of the xslt transform required
to achieve your solution. You could also add another CSS rule for tags inside
programlisting to my solution.
Your choice.
On 2010-06-08, at 19:10, André Bargull wrote:
I've attached a screen shot with both versions:
- left hand side: current patch
- right hand side: your proposal
Explanation for the pictures:
The current styles are displayed in the rounded rectangles. The struck out
style was just added to mimic Firebug's behaviour for overridden styles.
I'm slightly in favour of the output shown in the left picture. I guess it's
because of the small difference between the font-size for tags and code. Maybe
because the difference puts a bit more emphasis on the code, or rather less
emphasis on the tags, which are already coloured and therefore quite stressed.
On 6/8/2010 7:26 PM, P T Withington wrote:
Doh. Sorry. I was not paying attention. Now I see.
I commented on the bug with a possible alternative fix. If that doesn't work,
your fix is complex, but it certainly makes the examples much more useful, so,
approved (unless my alternate idea can be made to work).
On 2010-06-08, at 13:03, André Bargull wrote:
Hmm, it was you who filed LPP-5990...
Here's an example:
Page:
http://labs.openlaszlo.org/trunk-nightly/docs/developers/delegates.html#d0e78647
Source:
http://labs.openlaszlo.org/trunk-nightly/docs/developers/programs/delegates-$4.lzx?lzt=source
Files:
LPP-5990_example.png - how program listings look like without this change
LPP-5990_example_fixed.png - how program listings look like after applying the
change
On 6/8/2010 6:03 PM, P T Withington wrote:
On 2010-06-08, at 11:38, André Bargull wrote:
On 6/7/2010 4:42 PM, P T Withington wrote:
I'm pretty sure the 1.08 is me, because I find that the tty font looks too
small visually otherwise. I wasn't worried about the indenting, since it's a
fixed-width font.
If that is really of concern, I can only think of two other ways:
'of concern' in regard to find a different way to fix the indentation bug or
'of concern' in regard to fix the bug at all?
The latter. I'm trying to understand why having the spacing be proportional to
the font size is bad? Is there something particular I should look at? Do you
have a screen shot, perhaps?
1) adjust the tracking: letter-spacing: -0.08em
The spacing between characters becomes too narrow when the letter-spacing css style is set
to -0.08em for the complete<code> element. If the style is just set for
the<span> containing the leading white-space, the visual result is the same as for
setting the font-size to 0.926em. I guess you've meant to propose the latter.
Either one. I just suggested it as an experiment. Looks like it failed.
2) create a nested div for each level of indentation give those divs the same
padding as the single line code
On 2010-06-05, at 12:07, André Bargull wrote:
Do you know of a better way to handle this bug? IMO, this patch is a bit clumsy.
- André
Change 20100605-bargull-iBh by barg...@bargull02 on 2010-06-05 17:37:38
in /home/anba/src/svn/openlaszlo/trunk
for http://svn.openlaszlo.org/openlaszlo/trunk
Summary: improve appearance of leading white-space in<programlisting>
Bugs Fixed: LPP-5990 (xslt for<programlisting> formats code blocks poorly)
Technical Reviewer: ptw
QA Reviewer: (pending)
Details:
The programlisting's code font-size is set to 1.08em to improve readability
(see styles.css). But there arises one disadvantage:
increasing the font-size also increases the width of the leading white-space in
each line. This is clearly not intended. So we'd like to tell the css to
increase the font-size only after the leading white-space, but unfortunately
this isn't possible (at least I don't know how to do this). This is how I
worked around this problem:
- when the code is processed in lzx-pretty-print.xsl, I annotate all leading
white-space with a<leading-space> element
- and in common-html.xsl, the<leading-space> element gets transformed to a
simple<span> element with the "leading-space" css-class set
- the "leading-space" css-class has got a font-size of 0.926em, which is the
reciprocal of 1.08, so it effectively reverts the increased font-size of code blocks
styles.css also adds padding for code blocks, but this is actually only useful for
single-line code. Multi-line code are now marked with a "multiline" attribute,
so it's possible to attach a different css-class to those elements (see common-html.xsl).
Tests:
ant developers
open dguide chapters with programlisting
Files:
M docs/includes/styles.css
M docs/src/xsl/common-html.xsl
M docs/src/xsl/lzx-pretty-print.xsl
Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20100605-bargull-iBh.tar
<LPP-5990_example.png><LPP-5990_example_fixed.png>
<LPP-5990_Tuckers_proposal.png>
