Flying Rhino
RHINO AVIATION

Preflight Planning

Requirements

  • Templates may be RTF or plain DOCX files. The upload path accepts `.rtf` and `.docx` only.
  • DOCX means plain Word document only; `.docm`, `.dotx`, `.doc`, embedded active content, and macro-enabled documents are not accepted.
  • DOCX uploads require the server-side LibreOffice converter. The app preserves the DOCX source when the schema supports it and stores a converted RTF rendering copy internally.
  • Generated output can be RTF, DOCX, or PDF depending on the selected target and server converter availability.
  • If you edit a template outside the app, save it as RTF or plain DOCX before uploading.
  • On upload or replacement, the app warns about malformed or unmatched conditionals, iterators, and counted loops; invalid loop increments; invalid modifier syntax; and tokens split by embedded RTF formatting. You may cancel the upload or explicitly load the template anyway.
  • Template names are case-sensitive. Public template names may not duplicate an existing name. Different users may use the same name for private templates. Uploading the same private name again under your own account asks before replacing your existing template.
  • Deleting a template permanently removes it. Any saved-flight or user-preference reference to that template is cleared first.

DOCX Layout Limits

DOCX templates are converted to internal RTF when uploaded. Token substitution happens after that conversion, so use DOCX as an authoring convenience rather than as a guarantee that every Word layout feature will behave identically in every target app.

  • Keep each token as contiguous literal text, for example [DpWeather]. Do not split a token across runs with mixed formatting, fields, comments, or embedded objects.
  • [WBGraph] is the exception: its supported embedded RTF text-color controls select graph element colors and are accepted by upload validation.
  • Manual page breaks usually work when LibreOffice converts them to RTF page breaks. Notability has custom handling for literal RTF page breaks.
  • Paragraph settings such as “page break before,” “keep with next,” and “keep lines together” are passed through only if LibreOffice converts them into RTF controls. The app does not enforce those paragraph rules itself.
  • Multiple-column layout is not interpreted by the app. Word and PDF output may honor converted column controls, but Notability output should not be assumed to be column-aware.
  • For Notability-targeted forms, prefer the proven RTF template patterns with explicit page breaks and tab stops over complex DOCX layout features.
  • Notability does not reliably inherit character formatting across ordinary RTF groups. For Notability output, the renderer preserves the groups but explicitly repeats inherited font, size, color, bold, italic, underline, superscript/subscript, and Unicode fallback state inside body groups. Normal RTF group scoping may therefore be used in templates without duplicating those controls solely for Notability.
  • For Unicode with fallback text, set \ucN to the fallback length. For example, use {\uc1\u8226-} for a bullet with a hyphen fallback and {\uc2\u8594->} for an arrow with a two-character fallback. Notability tab expansion measures the Unicode character, not the suppressed fallback.

How Token Substitution Works

Any text in square brackets that matches a known token name is replaced during form generation. The token name must be exact.

  • [AcReg] inserts the selected aircraft registration.
  • [FlightType] inserts the flight type, such as IFR or VFR.
  • [WHATIF] inserts 1 when hypothetical weather is active for the generated form and is blank otherwise.
  • [ROUTE] inserts the Expected Route entered for a Single-Leg IFR flight, converted to uppercase with spacing preserved. It is blank for VFR and Multi-Leg flights. (Note that a blank [ROUTE] will test FALSE in a conditional. Note also that if the Expected Route is literally FALSE the [ROUTE] token will appear to be FALSE (i.e., not TRUE) in a conditional.
  • [ETE] inserts the ETE entered on the Flight page when Generate Form is run. It does not use the older ETE from the last Refresh Weather operation. If the ETE changed after weather was refreshed and the user accepts the stale-weather warning, the changed ETE is inserted.
  • [DpId] inserts the departure airport ident.
  • [DtId] inserts the destination airport ident.
  • [Dp.Weather#T] returns the departure weather type: A for actual current/forecast weather, I for ISA without overrides, or U for any user-entered field, even with ISA selected. The same modifier works with Dt, Ad, A1, A2, legacy A3, and FOREACH stop aliases such as i. An untouched airport remains A within a hypothetical scenario. Use [IF:Dp.Weather#T=U]USER WX[/IF] to label user-specified weather. Missing airports and older cached rows without type metadata return blank; refresh or recalculate to populate the metadata.
  • [DpRwy], [DtRwy], [DpGR], [DtOb], and similar tokens come from the weather/performance rows.
  • [File] and [Path] insert the template name.
  • [Source] inserts the template source format, either RTF or DocX.
  • [TemplateKey] inserts the special-character key, such as ε: estimated value; ® with runway: right traffic; © with tower frequency: CTAF used; ‡ with frequency: more than two same-type frequencies available; * with frequency: part-time facility.
  • [LBRACKET] inserts a literal [, and [RBRACKET] inserts a literal ]. Use them to emit text that would otherwise be recognized as template syntax.
  • [Target], [OutputTarget], [TargetApp], and [TargetFormat] describe the render and output targets.
  • [HOST] inserts host/IPv4/IPv6. Use [HOST#n] for the host name, [HOST#i] for IPv4, [HOST#q] for IPv6, or [HOST#z] for the server timezone.
  • [Options#W], [Options#R], [Options#C], [Options#S], [Options#I], [Options#V], and [Options#X] insert TRUE or FALSE for W&B, runway performance, consumables, V-speeds, IFR, VFR, and planning weather respectively.

Form Options

The Generate Form panel lets the user select W&B, runway performance, a consumables table, V-speeds, and planning weather. IFR or VFR remains a Flight-page selection. Use the option tokens directly in conditionals:

[IF:Options#R]Runway performance content[/IF]
[IF:Options#S]V-speed content[/IF]
[IF:Options#X]Planning weather content[/IF]
  • #W = W&B, #R = runway performance, #C = consumables table, #S = V-speeds, and #X = planning weather.
  • #I is true for IFR and #V is true for VFR.
  • Each token emits the literal value TRUE or FALSE.
  • An unavailable option is disabled and emits FALSE. W&B requires aircraft empty weight and CG plus forward and aft envelope boundaries; runway performance requires takeoff and landing profiles or the explicit legacy model. Without current weather, runway performance is initially unchecked but may be selected after confirmation. Consumables may be selected even when the aircraft has no tanks. V-speeds require V-speed data for the selected aircraft type. Planning weather requires a current weather panel for the current route and aircraft.
  • Existing [IF:IFR], [IF:VFR], and [WBGraph] templates continue to work unchanged.
  • What-if weather changes weather and runway-performance calculations, not loading. Fuel and W&B tokens continue to use the selected aircraft's current W&B loading.

Comments

Use either paired comment delimiters or a single comment token to keep notes in a template without emitting them in generated output.

[/*]This note and any template-looking text inside it are discarded.[*/]
[/* This single-token note, including an embedded ], is discarded. */]
  • The opening and closing comment tokens and all content between them are removed before template processing.
  • In the single-token form, an embedded ] is comment text. The first */ closes the comment text.
  • Only whitespace may appear between */ and the terminating ].
  • Conditionals, loops, and substitution tokens inside a comment are not processed.
  • Keep each comment marker contiguous; do not split [/*, */], [/*], or [*/] with RTF formatting.
  • Upload validation reports unmatched, unterminated, or malformed comments.

Token Families

Airport-family tokens use a prefix plus a suffix.

  • Prefixes: Dp = Departure, Dt = Destination, Ad = Departure Alternate, A1 = Alternate, A2 = Alternate 2.
  • Common suffixes: Id, Name, Rwy, Wx, Weather, Wind, Vis, Clouds, Temp, Dew, TZ, TPA, DA, Elev, Wgt, GR, Ob.
  • Airport Name tokens are limited to 20 characters on generated forms. A longer name is rendered as its first 19 characters followed by an ellipsis (…). The Flight page continues to display the full airport name.
  • Frequency tokens such as [DpWx], [DpClnc], [DpGnd], and [DpTwr] include up to two same-type frequencies. A trailing ‡ means additional same-type frequencies are available; a trailing © on tower frequency means CTAF was used because no tower frequency exists. Use #F to append * to displayed part-time facility frequencies.
  • Runway tokens such as [DpRwy] and [DpRwys] are unannotated by default. Use #R and #C modifiers when a template needs right-traffic or calm/preferred-runway annotations.
  • Dotted names are accepted for airport and V-speed tokens. For example, [Dp.Wgt] is equivalent to [DpWgt], and [Dt.Wx#F] is equivalent to [DtWx#F].
  • Example: [DtGR] means destination ground roll. [AdWx] means departure alternate weather frequency. [DpWeather] means departure weather summary, such as 340º@16G26KT 10SM CLR 16º/M02ºC or calm – – 13ºC/–.

Token Modifiers

Runway and frequency tokens support limited modifiers separated from the token name by #. Modifiers are case-insensitive.

  • #R applies the right-traffic marker when the runway is listed as right traffic.
  • #C applies calm-wind/preferred-runway underlining when the runway is listed as calm/preferred.
  • #F applies to Wx, Clnc, Gnd, and Twr frequency tokens and marks displayed part-time facility frequencies with *.
  • #D, #L, #A, #F, #Z, and #P apply to TZ timezone tokens. Examples: [DpTZ], [DpTZ#A], and [DtTZ#z].
  • #F also applies to the [Date] token and uses the flight ETD date/time instead of the generation date/time, for example [Date#F:Mmm d, yyyy].
  • Runway modifiers may be combined, for example [DpRwy#R#C], [DpRwy#RC], or [DtRwys#c#r].
  • Unsupported modifiers are intentionally left visible in the generated output so authoring errors are easy to find.

W&B Graph Token

[WBGraph] inserts the weight-and-balance graph when W&B output is included. Unlike ordinary tokens, it is inserted as raw RTF.

The token may include RTF color changes and these marker words. The renderer uses the color in effect at each marker word for the corresponding graph element:

  • DpColor: takeoff/departure point.
  • DtColor: destination/landing point.
  • A1Color: alternate point.
  • MTColor: empty-weight or zero-fuel point.
  • The color in effect immediately before [WBGraph is the base color for axes, envelope, and labels.
  • If a marker word is omitted, that graph element uses the base color.
  • width, height, and font arguments are not currently supported.
[WBGraph\cf7  \cf4 DpColor\cf7  \cf10 DtColor\cf7  \cf6 A1Color\cf7  \cf5 MTColor\cf2 ]

Date Tokens

Date tokens use the same format strings in all generated output formats.

  • [Date], [Date:yyyy-mm-dd], and [Date yyyy-mm-dd] use the form-generation date/time.
  • [Date#F:Mmm d, yyyy] uses the flight ETD date/time with the requested format.
  • [mDate] and [mDate:yyyy-mm-dd hh:nn] use the template-modified date/time in the server timezone.
  • [zDate] and [zDate:yyyy-mm-dd hh:nn] use the form-generation date/time in UTC.
  • Date formats may use timezone modifiers such as Z#Z, Z#A, or z#f.

Target Tokens

Target tokens allow one source template to adjust wording for RTF, DOCX, or PDF output.

  • [Target] resolves to the logical render target used for token substitution, with values such as Notability/rtf, Word/rtf, Word/docx, TextEdit/rtf, or PDF.
  • [OutputTarget] resolves to the final user-selected output target. For ordinary PDF generation, [Target] may be TextEdit/rtf while [OutputTarget] is PDF.
  • [TargetApp] resolves to Notability, Word, TextEdit, or PDF.
  • [TargetFormat] resolves to RTF, DOCX, or PDF.
  • [TargetRTF], [TargetDOCX], [TargetPDF], [TargetWord], [TargetNotability], and [TargetTextEdit] are true/blank flag tokens for conditionals.
  • Ordinary PDF generation uses the TextEdit/RTF logical target by default, then converts that RTF through LibreOffice. Select PDF (with TargetPDF tokens) if the template must see PDF-specific target tokens.

Fuel Tokens

Fuel tokens use the current W&B loading for the selected aircraft and emit gallons without units.

  • [Fuel] is total fuel at engine start.
  • [Fuel#L] and [Fuel#R] are total fuel in left-side and right-side tanks.
  • [Fuel#M], [Fuel#LM], [Fuel#RM], [Fuel#LA], and [Fuel#RA] use the aircraft type's fuel side and role mappings. Tip tanks count as auxiliary tanks.
  • [FuelDest] and [FuelAlt] are expected fuel remaining at destination and alternate.
  • [FuelUsedDest], [FuelUsedAlt], and [FuelUsedAltDelta] are fuel used to destination, fuel used to alternate total, and fuel used from destination to alternate.
  • Fuel tokens may be adjacent to ordinary text, for example FL[Fuel#L].

Conditionals

Conditionals use this exact syntax:

[IF:expression]text when true[ELSE]text when false[/IF]
  • A bare expression such as [IF:IFR] is true when the token is non-blank. Boolean token values are recognized case-insensitively: TRUE is true and FALSE is false. For example, [IF:Dp.TwrOpen]tower open[ELSE]tower closed[/IF] works directly with the tower-open token.
  • Equality tests use =, for example [IF:FlightType=VFR].
  • Inequality tests use !=, for example [IF:FlightType!=IFR].
  • Target-specific tests use the same syntax, for example [IF:Target=Word/docx] or [IF:Target!=PDF].
  • Combine expressions with & for logical AND, | for logical OR, and ! for logical NOT. Whitespace around these operators is optional.
  • All three logical operators have equal precedence and evaluation proceeds from right to left. Thus a & b | c means a & (b | c). Similarly, a & !b | c means a & !(b | c), not (a & !b) | c.
  • Use parentheses for explicit grouping. For example, !TRUE & FALSE is true, while (!TRUE) & FALSE is false.
  • Comparison operators remain part of one operand. Existing expressions using !=, !>, and !< continue to work.
  • [ELSE] is optional.
  • Directive names are shown uppercase for clarity; matching is case-insensitive. IF requires a colon after it.
[IF:Options#R | Options#S]Runway-performance or V-speed content[/IF]
[IF:Options#W & (Options#R | Options#S)]Combined optional content[/IF]
[IF:!Options#X & Options#R]Right-to-left NOT example[/IF]
[IF:WHATIF]HYPOTHETICAL SITUATION[/IF]

Multi-Leg Stop Loops

Multi-leg templates can repeat a block for intermediate stops. Departure, destination, and alternate airports are not included in STOPS. Routes are limited to 15 legs, so STOPS contains at most 14 intermediate stops; the alternate is not counted as a route leg. The iterator variable is a placeholder and may be any case-insensitive alphanumeric/underscore string, such as i, stop, or leg_1.

[FOREACH:i in STOPS]
STOP [i]: [i.Id] ([i.Name]; [i.TZ#A])
Arrive Rwy [i.Rwy.arr#R#C] [i.GR.arr] / [i.Ob.arr]
Depart Rwy [i.Rwy.dep#R#C] [i.GR.dep] / [i.Ob.dep]
[/FOREACH]
  • [i] is the 1-based stop number.
  • Common stop tokens include [i.Id], [i.Name], [i.Weather], [i.Wx#F], [i.TPA], [i.Wgt], and [i.Rwys#R#C].
  • Operation-specific tokens use .arr or .dep, such as [i.Rwy.arr#R#C], [i.GR.dep], and [i.Ob.arr].
  • V-speed tokens inside the loop include [i.Vr], [i.V50], [i.Vref], [i.Vappr], [i.Va], [i.Vb], [i.Vsink], and [i.Vg].

Counted Loops

Use [FOR] when a template needs a fixed number of repeated lines or columns.

[FOR:j=1..10/1]
Row [j]
[/FOR]
  • The loop counter is available as a token inside the loop, such as [j].
  • The start, end, and increment must be integers. The end value is inclusive.
  • The /increment part is optional and defaults to /1.
  • Positive and negative increments are supported. For example, [FOR:q=0..100/5] counts 0, 5, 10, and so on through 100, while [FOR:q=5..-5/-1] counts down.
  • A loop stops before stepping past the end. For example, [FOR:i=3..10/3] emits values 3, 6, and 9.
  • Counted loops may be nested inside [IF] and [FOREACH] blocks, and those blocks may also be nested inside counted loops.
  • Upload validation flags loops that cannot terminate, such as a zero increment or an increment that moves away from the end value.
  • A counted loop may execute at most 10,000 iterations. Upload validation rejects larger ranges, and generation fails instead of emitting a partial loop.

Blank True and Blank False

  • Blank True blanks flight-, aircraft-, W&B-, airport-, and weather-derived tokens, but forces all conditionals true.
  • Blank False blanks the same token families, but forces all conditionals false.
  • Date, file/path, source, template-key, and target tokens are still filled in, so those outputs are useful for template review.

Example 1: Simple Token Substitution

This example has no conditionals. It simply inserts the aircraft registration, departure, destination, and flight type.

Aircraft: [AcReg]
From: [DpId]
To: [DtId]
Type: [FlightType]

With a loaded flight, the generated output might look like:

Aircraft: N2FR
From: KPAO
To: E16
Type: VFR

Example 2: Simple Conditional Template

This example changes the text depending on whether the flight type token is IFR or VFR.

[IF:FlightType=IFR]Clearance: [DpClnc]
[ELSE]Departure CTAF/ATIS: [DpWx][/IF]
Departure runway: [DpRwy]
Departure ground roll: [DpGR]
Destination runway: [DtRwy]
Destination obstacle clearance: [DtOb]

For an IFR flight, the first line resolves to the clearance frequency. For a VFR flight, it resolves to the departure weather frequency line instead.

Example 3: Target-Specific Output

This example changes the text depending on the selected generated-output target.

[IF:Target=Word/docx]DOCX-specific checklist text.
[ELSE]RTF/PDF checklist text.[/IF]
[IF:Target!=PDF]Editable-form instructions.
[ELSE]PDF review-copy instructions.[/IF]

Because ordinary PDF output uses TextEdit/RTF tokens by default, use the explicit PDF-token target if this example must take the PDF branch for server-generated PDF output.

Practical Advice

  • Start with a very small template and test token names incrementally.
  • Use Blank True and Blank False on the Templates page to verify your conditional structure before using the template on a real flight.
  • If a token stays visible in the output, it usually means the token name is not recognized exactly as written.
  • Use [LBRACKET] and [RBRACKET] when bracketed text would otherwise be recognized as template syntax. For example, [LBRACKET]IF:IFR[RBRACKET] emits [IF:IFR], and [LBRACKET]/* emits [/*. Emitted literal text is not processed again.
  • The repository includes Test-*.rtf templates that exercise target tokens and conditionals.