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>
