The bug is either in Dorico or my brain (please confirm):
A flow title that is only a number followed by a period (e.g. 143. ) will not appear unless the number is more than 999999999. If there is any other alphabetic character the title will appear. So:
I wanted to title my flows 1. 2. 3. etc. Took a long time to narrow this down. Can someone please check it.
The same thing happened to me about a month ago. And it still occurs.
In the Project Info box - in the Title field - if the first thing you type is any number followed by a period, the number and the period will not appear. If you remove the period, the number will appear. This happens in many different files.
Seems to work fine for me, unless I’m misunderstanding:
Can you send a screenshot and maybe a cut-down file?
For the sake of expediency, I won’t explain why, but make sure that check box in project info is not checked, and you can write dots to your heart’s content.
Are you following these steps?
Start a brand new project. Add a piano for instance. Go to the Project info - under Title - type “1.” BEFORE the text already there (Untitled Project) . It will not appear.
Yes the number does appear then. But if you use other formatting, such as bold or italics, that won’t work.
True enough. That’s why I tend to write dots the flow header templates. Not saying it solves everything
I noticed this some time ago. My solution is to not have any numbers at the start of the Flow Title and then use the token for Flow Number.
Ahh you said Flow Title (as per the thread name) when you actually mean Project Title.
In that case, you’re correct: it does not appear.
I found a workaround: Put a non-breaking space (Alt-160 on Windows.) before the number. Only makes a minor alteration to the layout. Shouldn’t be necessary, though.
And why does the problem not happen if the number is greater than 999999999? That’s the real puzzle!
Unchecking that box DOES solve the problem! (Not that I know what ‘Resolving Markdown formatting for text tokens’ means and whether or not I want to do that.)
The cause is most likely that Markdown is parsing something like 1. or 2. as the first item of a numbered list (search for “fruits” on that Wikipedia page and you’ll see the markdown example).
Most likely once it gets recognized as a numbered list, it is probably split into two elements in a sort of array, consisting of the number and the text, and the token is only pulling the text component. When markdown does not recognize the opening label as an index for an entry in a numbered list (by having 1a for instance), the entire thing is simply treated as a text literal instead of being split into two elements, and then the token displays the whole thing.
I’m not sure why this behaviour would be desirable. It probably makes more sense to have the token resolve to both the number and the text in cases where it gets identified as a numbered list and auto-splits into the index and value. I suspect this was probably an oversight and was not intended.
The “intended” way to avoid it would be to put a backslash (\) before the period: 1\. (or uncheck the Markdown checkbox in project settings).
The backslash won’t appear on page, and it will cause the period to not be interpreted as something that would create a numbered list item.
This works for anything that happens to turn into Markdown formatting where you don’t want it to. I.e., a single asterisk can similarly be written with \*. And an initial dash can be written \- ever after in order to display “- ever after”. (Technically, of course, the correct solution in that particular case would be to use an actual dash character rather than the hyphen key on the keyboard - this is just for illustration of the principle 
). Or, to write “M*A*S*H”, you’d need to write M\*A\*S\*H in order for the asterisks to not be interpreted as markers for italics. (Technically, you’d only need the first two backslashes in this case, but the third doesn’t hurt).
Unlike the backslash, the non-breaking space will actually be included on the page, meaning the title will be off center.
The technical reason why 9999999999 will not cause the problem is that Markdown (or rather, CommonMark) specifies that an ordered list item may use 1-9 digits (and the even more technical cause for that “limitation” is that most numbers with 10 digits cannot be represented as a 32-bit integer).
Thank you, Michael.
Who knew you could use Markdown formatting in titles? Sweet.
