Tinderbox User-to-User Forum (for formal tech support please email: info@eastgate.com)
Tinderbox Users >> Exporting from Tinderbox >> Controlling formatting on export

Message started by J Fallows on Sep 30th, 2014, 4:23pm

Title: Controlling formatting on export
Post by J Fallows on Sep 30th, 2014, 4:23pm

This is a followup to Mark Anderson's very useful step-by-step export primer (http://www.eastgate.com/Tinderbox/forum//YaBB.pl?num=1412015986), and his followup post on how, exactly, you get the template files going in the first place (http://www.eastgate.com/Tinderbox/forum//YaBB.pl?num=1412032921/7#7)

I am now exporting away happily with the guidance you have provided here. Two further specific questions:

1) Controlling text size. I find that if the body text in some notes I am exporting is 14pts or below, the template renders it as body type. If it is larger than 14 points, it renders it at "h2"-style boldface headline type.  The image below shows two notes. In one the body style in $Text is 13 points; in the other, it is 15 points. The export program, using the same template, renders one as plain text and the other as "h2."

I understand the intention here. But am I right in assume that these conversions can be customized, or over-ridden? Is there something I can do in the template that will coerce it to treat the first line only as the title, and everything after that as body text, no matter its size? Just trying to develop a sense of what I can control.

2) What is the canonical source for syntax questions like these about export codes? For agents, queries, and all other TB issues, I view aTbRef in that role. Should I also view is as the authoritative source for export code?

Here a screen shot showing two notes, in one of which the body text has been converted to headline style. To be clear, they're both using the same export template.

Title: Re: Controlling formatting on export
Post by Mark Bernstein on Sep 30th, 2014, 4:47pm

The markup of text as body text or heading is based on the note’s default text size -- which is typically set in Document Settings:Text.  So, if your document uses 14pt Helvetica as its default text, then 16pt will be interpreted as a heading.

Format>Style>Standard Size restores the selection to the default size.

The code is definitive, but right now aTbRef is your best source for export code.  Note that export code used to be a lot more complicated than it is today!  Nowadays, ^value() and ^text may be everything you really need.

Lots of new Tinderbox Help is on the way as well.

Title: Re: Controlling formatting on export
Post by Mark Anderson on Sep 30th, 2014, 6:17pm

Further to MB's comment, my notes have this:

Text set 2-3 points larger than body text ($TextFontSize) is exported to HTML as <h3>, 4-5 points gives <h2> and 6 or more points above body copy is exported as <h1>. Generally this is a useful enhancement but it can be problematic if the text size has been enlarged only for clarity within Tinderbox itself.

Above text copied from here in aTbRef.

To give context, the feature makes more sense if one understands it dates from before TB acquired many of its current (v6) rich text styling features, when setting varied font sizes was a less common and more deliberate choice.

Of course, if you've existing docs where you've used varying font sizes but have never really used export before these 'automatic' headings may come as a surprise. It I recall there's no way to turn them off (separately from any other feature). I'm sure the planned review of TB export will address these effects of ageing in due course.

Title: Re: Controlling formatting on export
Post by J Fallows on Sep 30th, 2014, 7:22pm

Dear Marks A and B:

Thanks for the guidance. I am sure you have accurately diagnosed the situation. Also I understand the historical explanation of why this approach made sense in a different era of text display.

Mark A says:
Of course, if you've existing docs where you've used varying font sizes but have never really used export before these 'automatic' headings may come as a surprise.

Yes, that's true. It's an impediment with a large set of notes I have, whose $Text is in a wide variety of type styles and sizes—often because I cut-and-pasted them in, some because I wanted to make them larger in certain circumstances, etc.  Until today I didn't know that many of them would get converted into all-headline style. On the other hand, until today I didn't know how to export any of them, so I'm still ahead.

I will assume that there is not an automated way either (a) to write a template that would strip out "<h2>"-type code, or (b) to use Markdown etc code to override the headline conversion. I assume that, because if there were a way you would know about it!

So I do understand what is happening now, and when it really matters I can go in and change the underlying size/style of the $Text in the note.

Update: I tried to see if I could outwit the conversion algorithm. I went in and changed the default text size, via Edit/Document Settings/Text, which had been 12 points, up to 16. Then I checked to see whether some notes with 15- or 16-point type, which had been auto-converted to headlines, would now just be body text, since they'd be no larger than the new, bulked-up default size.

The program didn't fall for it! Maybe the notes retain the "relative to default text" setting they had when they were created? With the default set to 16, notes with 12-point type still were body text, and notes with 15-point type were still converted to headlines, as they had been when the default was 12.

At least I tried!

Update-update Mark A, does this passage from aTbRef mean that by changing the template setting from ^text to ^value($Text) or ^text(plain), I can turn off the auto-headline feature?

If instead ^value($Text)^ or ^text(plain)^ are used to export $Text, the above effects are by-passed.

Answering my own question: Yes, ^text(plain) turns off auto-headlining, but it also turns off all other formatting so you just get a stream of non-paragraphed text. Again, I tried!

Title: Re: Controlling formatting on export
Post by Mark Anderson on Oct 1st, 2014, 3:34am

@JF. Chapeau for trying - it's often the easiest way to see what one otherwise only reads about. Yes, you are correct ^text(plain)^ and ^value($Text)^ both bypass the HTML encoding of $Text so you lose all formatting. Did you also try MB's suggestion of the two new v6 menu items: Format menu -> Style -> Standard size and Standard Font. These should - if I understand correctly - set the selected $Text to use the note's original $TextFont and $TextFontSize.

The relation of $TextFont and $TextFont to $Text has always been hazy - at least for me. All they seem to do is to determine the initial font/size to use when first entering data into text. As soon as $Text is touched for the first time, all $Text including runs of text at the default size/face have those settings encoded. This is why since v5 added paste-and-match-style I've used that instead of normal paste for text copied from other apps, so as to avoid $Text looking like a home print set.

In v5, the 'master' was the plain text with a separate RTF versions holding the same data plus any non-XML-encodable styling such as highlighting. In v6, this appears to flip so the rich text is now the master - to support all those extra text style features so many people demanded - whilst a  plain text XML copy is also stored, though unlike v5's XML without bold and italic runs because these are now done desktop-publishing style by setting a different font version. This also explains why v5 docs using a $TextFont of Lucida Grande lose all their italic formatting in v6 as there is no italic face for (Apple) Lucida Grande. Also of note, for anyone minded to look at a TBX's source XML, the rich text in v6 is stored in RTFD format (what is RTFD?). RTF was sort-of human readable; RTFD not so. In effect it's now impossible without an RTFD parser to looks at a TBX source and figure what the text styling is.

This is a necessary halfway house. Holding up rich text improvements to v5 standard would have made using the new frameworks harder. Plus the new UI, the loss of the old export views means export is due for some updating/improvement. My reading of things is that until v6.0.x finishes tweaks to the the new UI, export will broadly remain as is until v6.1 (I amy be corrected on this). That said, some improvements are on the way before such a major review  - but which I can't talk about here as it's still in beta.

Tinderbox User-to-User Forum (for formal tech support please email: info@eastgate.com) » Powered by YaBB 2.2.1!
YaBB © 2000-2008. All Rights Reserved.