zim-wiki team mailing list archive

[Paulo van Breugel <p_vanbreugel@xxxxxxxxx>]

Sounds like a useful feature, providing maximum flexibility. Brilliant!

On 22 August 2014 19:06:11 CEST, Jaap Karssenberg <jaap.karssenberg@xxxxxxxxx> wrote:
>On Fri, Aug 22, 2014 at 6:56 PM, Paulo van Breugel
><p_vanbreugel@xxxxxxxxx>
>wrote:
>
>> You wrote: "Now as you commented correctly this results in a lot of
>> whitespace below the H2. But there is also space below the H1 that is
>not
>> in the wiki text."
>> --> This is just the default space after headers. As you mention
>below,
>> this can be easily handled using CSS.
>>
>> You wrote: "If I use CSS to remove the padding/margin between heading
>and
>> paragraph it looks again same as the source text. But in that case
>the BR
>> is crucial."
>> --> I don't see why the BR is crucial in that case.
>>
>
>
>Well, for those that expect WYSIWYG behavior, this BR is crucial to
>achieve
>the same result as in the wiki page.
>
>
>
>> You wrote: "Compromise would be to make the newline handling an
>option you
>> can control from the template. This could help to make "vanilla" HTML
>> export look decent while templates with CSS can set the BR how they
>want
>> it."
>> --> It seems setting the height of the BR, and that doesn't seem to
>be
>> easy:
>>
>http://stackoverflow.com/questions/1409649/how-to-change-the-height-of-a-br
>>
>
>That is not what I meant. By making it a template option, you would
>allow
>to choose in the template whether or not the BR are inserted at all.
>
>Similar there can be an option to add BR at the end of line in a
>paragraph
>or not.
>
>This would be in the zim output code, so independent of what you can do
>with CSS on top of that.
>
>
>
>> I think the situation is that in Zim, being text based (and given
>that the
>> text files should remain human readible), spaces between headers and
>text
>> can only be created by adding empty lines. In HTML such spaces should
>not
>> be done by adding breaks, but by using CSS. For this reason, the way
>empty
>> lines are handled in revision 706 is the correction one I think and
>the
>> changes should not be rolled back i.m.o.
>>
>> I am not sure if I understand the last option, but if that means the
>user
>> has the option to determine how empty lines are handled by the export
>> (being replaced by brakes or ignored), that would be a very nice
>feature.
>>
>
>Yep, that's what I meant :)
>
>Sounds like there is need for both options.
>
>Regards,
>
>Jaap

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.