Improving formatting and next steps

[HansOlsson]

I believe we need to make a plan for future steps, in particular:

• Goals for style updates (e.g. look and feel, better flow on small screens, less tex-hacks, easier to reference items). Note some stylistic updates are just tex/xml settings, others will need many updates of the document - e.g. replacing tables with something else.
• Revisit schedule: Style update, Correcting Bugs, Adding Features, Release plan

The online meeting design meeting 2018-09-28 had the following next steps:

• [x] Move to right place, i.e. from https://github.com/HansOlsson/ModelicaSpecification to something like https://github.com/modelica/ModelicaSpecification
• [x] Convert trac-ticket (@beutlich)

And for the next meeting:

• Style questions, e.g. how to handle tables
• Examples and non-normative text: how to format and mark-up
• Style: “Corporate” style-guidelines (@GallLeo is investigating in general)
• Style: Paragraph style (@henrikt-ma)
• Pull requests for improving formatting
• Split master<->3.4 before adding new contents
• Ideally before next design meeting

[HansOlsson]

1. Henrik: Check the chapters, some examples seemed out of order. Each person assigned one part of the document. (Synchronous seem to miss some images.) Page number in original pdf. Axel&Jesper page 1-60. Stefan,Jens 61-120. Niklas&Gerd 121-180. Henrik,Quention: 181-240 Hans, Michael: 241-300

2. Settle design issues - especially things that require many changes. In general replace tables (e.g. for operators) with sub-section for each item, and a short table with just links to these sections. (Or even just a list of "section operator" - the headings should not include the arguments; especially not if there are multiple variants). (Hans converts - if possible, or ask for help.) Minor style sheet issue: arrow to the right on each source example. Font for examples.

HTML-version should be main target (since it works better on small screens).

Change paragraph style to not indent, but only have vertical separation. (10 in favor, 0 against, 0 abstain.) Use parskip-package.

Simplify references by removing jsessionid.

Automatic creation of html and pdf-files (M. Sjölund) after commits.

[HansOlsson]

Result of distributed review of document:

The PDF table of contents (the meta-information, not the table of contents that appears in the pages of the document) only includes links to chapters.

• Page numbering starts on the copyright page, not after the contents as in the original
• Front page/abstract page – the modelica logo is after the "Abstract" header, and the abstract text is on the next page
• Abstract page/copyright page – the web links are formatted differently (they are at end of abstract & start of copyright). (Later web links are also strange, colored pink.)
• Copyright page – reference to appendix says only “E”, nor “Appendix E”
• Contents: "Preface" is missing 12.5 & 12.6 are missing 16.10, 16.11 & 18.10 – no space between chapter number & title 18.11 & 18.12 are missing ** “Index” is missing
• In general – fixed-width font inline in paragraphs lost
• Page 10 – no lines between rows in table
• Page 13 – lists of Real literals are very close together
• Page 15 – table referred to as just “the table:”, should probably refer in another way since ti is not guaranteed to be right after in latex. Ordering becomes a bit weird as well.
• Page 17 – the tables look weird
• Page 19 – definition of time – code formatting lost (no newline)
• Page 24 – in title of 3.7.2.2, spatialDistribution lost capital D
• Page 24 – indentation lost in syntax for spatialDistribution()
• Page 28 – "lambda" has been turned into an actual lambda, but earlier in the subsection on homotopy it is written out, even in what looks like it should have been a formula
• Page 36 & 42 – bold-face lost in EBNF
• Page 45 – operator record - one of the in-line code snippets became a code block, the other one did not
• Page 46-48 – all “Defenition #: [..]” & “Proposition #:” lost boldface
• Page 48-49 – some equations after example 1 and after example 2 lost indent
• Page 59 – original contains invalid reference "18.618.7", that was changed to 18.6 in new version, but should probably be 18.7
• Page 60 – subsection "Example of Field Functions using Inner/Outer" turned into just a line of text

Page 61-120 - Too many missing cases of typewriter/code text throughout these pages to mention separately. 5.6.1.4.x - These sections did not have numbers in the original document. 5.6.1.4.2 - Last three links refer to 12.5, 12.6, 12.7, but were 12.7 to 12.9 in the original. 5.6.2 - This section heading has just become a plain paragraph (i.e. there is no 5.6.2 any more).

• Should be a line break after "]" and before "The flat equation system ..." 6.1 - Figure 6.1 does not appear until part way through section 6.2 6.3 - (and probably elsewhere) Things like "Chapter 14" and "Section 12.97" have become just "14" and "12.9.7" 6.4 - "Definition 5" and "Definition 6" have lost their highlighting/heading-ness. 6.5 - "Definition 7", as above. 7.1.3 - Restricted classes table is too compressed vertically. 7.3.1 - Last two paragraphs should be in italics I think (this was broken in the original too). 8.3.5.3 - The two bullets each have some corresponding non-normative text, but in the first bullet, it just appears in-line, whereas in the second it starts a new non-indented paragraph. It was more consistent in the original, but I'm not sure which is correct. 9.1.3 - 2nd to 4th bullets should be one level deeper.
• Last bullet goes on too long compared to original. 9.2 - Typesetting of 3rd and 4th bullet is weird. Is it code? Sans-serif font suddenly appears. 9.4.1 - Contents of left column of table should be in code font.

page 121-180 (numbers in new) p105 Code font for data types Ch 10 /Introduc p105: Table at end of page parted p110: and following Indentation just weird p111: end of 10. Code formatting missing in plain text outside of examples p113: Table 10.7 Code partly in boxes p114: Examples too tight/not enough space p115: Table 10.9 "cross" is written in red(?) 115: "Real" red 116: Chapter 10.4.1. First code exp with backslah Ch 10.4.1.1 Example wrong position or Wrong example (from above) original text missing Ch 10.4.1.2 Last part after "concatentation" formatting wrong p118: Ch 10.5 Example section code formattingp120: Table numbering wrong in old doc. 10.14 twice

• sometimes missing closing bracket Example section p122: Ch 10.6.8 Example not as example formatted p123: Section missing in see 12.4.6 (intentional) p125: Ch 11.1 Formatting alg section, 11.2 Syntax code formatting p127: Use of boxes for examples or syntax is inconsistent p129: Syntax in box? p133: Ch 12.1.2 box around return; ? p136: Ch 12.4 Link to 12.4.9 correct (old doc 12.6) p142: Ch 12.4.8 should 12.5 (and 12.4.9 should be 12.6) p150: Ch 12.5.2. "IDENT=der(" is now bracketed

13.2.4

• Hyphenation of "MODEL-ICAPATH" (should appear without hyphenation)

13.2.4.1

• Reference to Figure 13-1 is not linked
• The actual figure of Figure 13-1 is missing.
• Unexpected boldface of the Figure 13-1 caption (and no boldface for "Figure 13-1" in the caption)

14

• "subtyping see 6." -> "subtyping see chapter 6." (this type of fix is is probably needed everywhere there is a link to a section)

14.2

• "exists a unique function" missing emphasis on "unique"

14.3

• "If A is a predefined type" missing emphasis on "type"
• "If A is an operator record class and" missing emphasis on "record class"

14.4

• "if there exists exactly one function" missing emphasis on "exactly one"
• "if a or b is an array expression" missing emphasis on "array expression"
• "product of Table 10.16 does" missing hyperlinking of "Table 10.16" (probably true for table links in general)
• "shall not exist any" missing emphasis on "any"
• Too many "missing emphasis". Will not report more of these in the rest of chapter 14.

15.1

• Figure 15.1: Figure appears below figure title (as if it were a table).
• No reference to Figure 15.1 in the text, and now it appears in a location where this is really needed.

16.1.1

• "A continuous plant and a sampled…" actual figure is missing
• "The approach in this chapter is based…" no hyperlinks to references in this paragraph

16.2.1

• "The different kinds of discrete-time variables in Modelica" all graphics in the table are missing
• "are constant inside each" missing emphasis on "constant".
• Too many missing emphasis. Will not report more of these in the rest of chapter 16.

16.2.3

• Definition of "Component Expression" is missing indentation of definition body (which looks like just another paragraph)
• "The input argument is a Component Expression" has lost the alignment of comments in the Modelica code snippets
• "Note that operator" has super ugly amounts of whitespace to avoid ragged lines (will probably be fixed when this is a separate section instead of a table entry)
• "Clock with Boolean Condition" suddenly the vertical alignment of the left column has turned from center to top

16.7.2

• "graph <N, F>" has a line break after "N,", space needs to be non-breaking
• "F={(e,v): eE,vincidence(e)}" missing "element of" operator

16.7.4

• Definition after "the following incidence definition" is missing the increasing amounts of indentation of each line
• Equation after "output variables):" is missing

16.8.3

• Code snippet is missing unusual alignment on "=" (new version looks better)

Page 210-305... 17.2 Link to 18.6.5 is link to 18 17.2 transition (and initialState) not keyword in grammar? 17.3.1 Need better formatting of code 17.3.2 Some weird paragraph formattting 17.3.7 Second figure (plot) is misplaced (and paragraph) 18.8.2.1 Conversion rules - more code blocks for convertModifiers etc 18.8.4 Code block for versionDate definition etc Boldfacing of keywords missing in B.2 Equation missing in C (before table) Figure 5 in D.1 (wrong aspect ratio) Figure 6 in D.2 (includegraphics missing slash) D.3.3 too long equation, missing equation in heading and missing figure E.3.3. "are appreciated" part of name-list

[HansOlsson]

Mono-spaced (needed since so common):

• Modelica as Modelica code
• Everything else as texttt - can later review to see if common variants Any volunteer? Check with backoffice.

[HansOlsson]

(100% updated.)

Remaining local issues for LaTeX-experts (none seem blocking):

• [ ] Page numbering starts on the copyright page, note - there is a subtle issue with page-number in pdf-document
• [ ] Front page/abstract page – the modelica logo is after the "Abstract" header, and the abstract text is on the next page. (Defining title-pages that work in the html-variant wasn't easy.)
• [ ] Keywords in grammar differ by color not bold-face.
• [ ] Restrictions on the Kind of Base Class table is too compressed?
• [x] Inline code font seems a bit on the small side?
• [ ] The equation in "Generation of Connection Equation does not look nice". It is written as inline Modelica code, since non-inline doesn't work well in itemized list.
• [ ] Definition/proposition are not proper LaTeX-items. (10+ places to change.)

Issues that will require updates in many places:

• [x] Mono-spaced text inline in normal text (depending on contents use listing for Modelica or texttt). Back-office?
• [ ] Index is missing (Note: The previous index wasn't ideal; so we should preferably make new one.)
• [x] Replace \ref by \autoref. The reason for this is that the chapter/section text is removed in front of the number, because we discussed having section-names instead of section-numbers in references, and that could look odd in combination, and autoref adds it automatically and consistently.

Deliberate changes:

• Proper lambda in homotopy (entire section).
• Some inline images replaced by proper figures with captions.
• Code alignment in 16.8.3
• The production annotation renamed to annotation-comment. Previously annotation was both a keyword and a production - that was confusing and the automatic syntax highlighting made it worse.
• The syntax highlighting is consistent; and thus keywords are always marked in the same way. It may be wrong - but at least consistently wrong.

BTW: In case someone wants to convert other non-bitmap images from Word to LaTeX the procedure that was used is: copy image to a separate Word-document, shrink the page size in Word, then export as PDF, and separately make a PNG.

[HansOlsson]

Note: It is possible to reconfigure autoref, e.g. to replace subsection... by section... by using the command \def\subsectionautorefname{section}.

[HansOlsson]

Planning of remaining actions:

1. Back-office corrects missing mono-spaced font in text (lots of places) - February.
2. Consider 3.4 to be fairly complete at that point, and make a branch/tag.
3. Merge pull-request and decided changes on master branch.

And update work-flow.

[henrikt-ma]

What about the big piece of work to fix the formatting of all inline code? Has there been any progress in this area since the last design meeting? I find this the most urgent item of all, and something we really should complete before we consider the transition to LaTeX sources done and that we have an acceptable re-release of 3.4. The other items seems to address various things that we should now be able to improve over the old Word-based specification, whereas formatting of inline code is simply broken and makes the old specification a lot more readable than the new one.

Henrik

On 2019-02-14, at 11:44, Hans Olsson notifications@github.com wrote:

I believe we need to make a plan for future steps, in particular:

Goals for style updates (e.g. look and feel, better flow on small screens, less tex-hacks, easier to reference items). Note some stylistic updates are just tex/xml settings, others will need many updates of the document - e.g. replacing tables with something else. Revisit schedule: Style update, Correcting Bugs, Adding Features, Release plan The online meeting design meeting 2018-09-28 had the following next steps:

Move to right place, i.e. from https://github.com/HansOlsson/ModelicaSpecification https://github.com/HansOlsson/ModelicaSpecification to something like https://github.com/modelica/ModelicaSpecification https://github.com/modelica/ModelicaSpecification Convert trac-ticket (@beutlich https://github.com/beutlich) And for the next meeting:

Style questions, e.g. how to handle tables Examples and non-normative text: how to format and mark-up Style: “Corporate” style-guidelines (@GallLeo https://github.com/GallLeo is investigating in general) Style: Paragraph style (@henrikt-ma https://github.com/henrikt-ma) Pull requests for improving formatting Split master<->3.4 before adding new contents Ideally before next design meeting — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/modelica/ModelicaSpecification/issues/2284, or mute the thread https://github.com/notifications/unsubscribe-auth/AYH1P6qU-Q-8DoTUIUU4booph-rzljrmks5vNT4kgaJpZM4Y1Oe6.

[HansOlsson]

What about the big piece of work to fix the formatting of all inline code? Has there been any progress in this area since the last design meeting?

Yes, I know the work has started, and according to the plan it should be done any day now. @GallLeo should have more detailed information.

[GallLeo]

Hi Hans and Henrik,

You can have a look at the current status in my fork https://github.com/GallLeo/ModelicaSpecification Yes, it is quite a junk of work. So far, Sonja and I have spent about 2.5 ... 3 days of editing.

Couting pages of the MLS document, it's 63 % done. But, timewise, the rest should go quite quickly. I can let you know a planned date for finishing this work on Monday.

For some things, we might need your input. E.g. Chapter streams: https://github.com/GallLeo/ModelicaSpecification/blob/master/chapters/stream.tex#L155 In the current specification m_j is not really Modelica syntax and therefore also the code-blocks have been converted in an incorrect way. Should we change this to m[j] or use proper Latex commands instead of verbatim text?

[henrikt-ma]

It is wonderful to hear that this work is in progress, and that you've actually completed most of it!

I had some problems building the document, and found entire sections typeset in teletype font, but I guess it's too early to mention details.

What I'm wondering, though, is whether the pretty verbose style of \lstinline[basicstyle=\ttfamily]!start! really is how we would like to have it in our sources. Wouldn't it be much nicer if there was just a macro without any need to set options, like \modelica{start} or \inlinemodelica{start} (but I think shorter is better since this is used so heavily)?

Not that it's a big concern right now, since I'm assuming that it should be fairly easy to automatically replace them all once you're finished.

Henrik

On 2019-02-15, at 10:35, Leo Gall notifications@github.com wrote:

Hi Hans and Henrik,

You can have a look at the current status in my fork https://github.com/GallLeo/ModelicaSpecification https://github.com/GallLeo/ModelicaSpecification Yes, it is quite a junk of work. So far, Sonja and I have spent about 2.5 ... 3 days of editing.

Couting pages of the MLS document, it's 63 % done. But, timewise, the rest should go quite quickly. I can let you know a planned date for finishing this work on Monday.

For some things, we might need your input. E.g. Chapter streams: https://github.com/GallLeo/ModelicaSpecification/blob/master/chapters/stream.tex#L155 https://github.com/GallLeo/ModelicaSpecification/blob/master/chapters/stream.tex#L155 In the current specification m_j is not really Modelica syntax and therefore also the code-blocks have been converted in an incorrect way. Should we change this to m[j] or use proper Latex commands instead of verbatim text?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/modelica/ModelicaSpecification/issues/2284#issuecomment-463970129, or mute the thread https://github.com/notifications/unsubscribe-auth/AYH1P9HKNN8oRQ-3UW2d8RUhVuIIWcfbks5vNn9ngaJpZM4Y1Oe6.

[HansOlsson]

What I'm wondering, though, is whether the pretty verbose style of \lstinline[basicstyle=\ttfamily]!start! really is how we would like to have it in our sources.

The standard variant is just \lstinline!start! and I would assume it would be possible to change the default style for this command to avoid the extra argument.

A normal macro would likely be more complicated since it may contain characters that need quoting etc. I assume it would be possible to construct a special command as \modelica!start! but I don't know how.

And speaking of quoting:

For some things, we might need your input. E.g. Chapter streams: https://github.com/GallLeo/ModelicaSpecification/blob/master/chapters/stream.tex#L155 In the current specification m_j is not really Modelica syntax and therefore also the code-blocks have > been converted in an incorrect way. Should we change this to m[j] or use proper Latex commands instead of verbatim text?

I see,. I agree that is broken, and technically it wasn't really Modelica before as it is intended to show different component called m_1, m_2, m_3 - not elements of an array of components.

One attempt to make it really nice is found on: https://github.com/GallLeo/ModelicaSpecification/blob/master/chapters/stream.tex#L203 But it seems mathescape only works in PDF not HTML. Whereas normal escapechar work in both (used in function chapter).

[henrikt-ma]

On 2019-02-15, at 11:56, Hans Olsson notifications@github.com wrote:

What I'm wondering, though, is whether the pretty verbose style of \lstinline[basicstyle=\ttfamily]!start! really is how we would like to have it in our sources.

The standard variant is just \lstinline!start! and I would assume it would be possible to change the default style for this command to avoid the extra argument.

A normal macro would likely be more complicated since it may contain characters that need quoting etc. I assume it would be possible to construct a special command as \modelica!start! but I don't know how

Wouldn't a normal macro be required if we wanted some syntax highlighting of keywords, etc, inside the inline code, or can lstinline be tricked to do such processing on the fly? If not, I would still consider it an alternative to use normal (the-non-verbatim-kind) macros, so that we at least can get syntax highlighting of keywords in the inline code. I think that this would be a minimum amount of syntax highlighting expected of a modern specification document. It is true that we would need to deal with escaping of some characters, but that's a fairly small price to pay.

If we can't find a macro for inline formatting of code that automatically does keyword highlighting, we could always consider doing this markup by hand (but not before branching off a new master, since we didn't have this type of syntax highlighting in the old Word document either).

Henrik

[HansOlsson]

Wouldn't a normal macro be required if we wanted some syntax highlighting of keywords, etc, inside the inline code, or can lstinline be tricked to do such processing on the fly?

lstinline is an inline variant of listings-environment so it automatically does syntax highlighting according to Modelica-syntax (well, the default language which happens to be Modelica). If we didn't want that we could just use some of the verbatim-variants.

As for defining our own variant I looked in 4.17 of http://mirror.hmc.edu/ctan/macros/latex/contrib/listings/listings.pdf

\lstMakeShortInline[<options>]<character> defines <character> to be an equivalent of \lstinline[<options]<character>, allowing for a convenient syntax when using lots of inline listings.

[GallLeo]

@henrikt-ma: Before starting, I tried to write a LaTeX macro, but there was no such nice solution as \lstinline. The current command has the drawback that it needs ! but the big benefit that the inline code looks exactly the same as the other non-inline code blocks in the specficiation. I did use the verbose argument [basicstyle=\ttfamily] in order to de-couple the font size of the inline code from the non-inline code blocks. To my eye, the inline code-blocks should have the same size as the continous text, while non-inline code blocks can be smaller in order to fit more code on one page/screen.

@HansOlsson: Thank you for the tip! I was searching for such a command, but it seems I did not read the package documentation closely enough. We are going to test \lstMakeShortInline and if it works, automatically replace all instances of \lstinline[basicstyle=\ttfamily]. Which abbreviation would you prefer: \mo \moinline \mocode \modelica?

[HansOlsson]

Which abbreviation would you prefer: \mo \moinline \mocode \modelica?

Hmm... Not sure which one I prefer; but \modelica has the advantage that it is easy to find and avoids using abbreviations.

Regarding the non-inline code in the streams-chapter I could ensure that it is as in the Word-document, or use escape to use italic without math or subscript for the indices to indicate that it is something special.

[MABackoffice]

As proposed by @HansOlsson, I tried to get a shorter version of command \lstinline[basicstyle=\ttfamily]. For this, <character> really means a single character, like | or @ (https://tex.stackexchange.com/questions/135416/lstmakeshortinline-with-delimiter).

For testing, I defined the pipe symbol: \lstMakeShortInline[basicstyle=\ttfamily]| % option to use |...| for inline Modelica code

This would work, would be much less verbose, but would mean that we have to find all trailing ! when replacing all instances of \lstinline[basicstyle=\ttfamily].

What do you think? And which character would you pick?

[HansOlsson]

What do you think? And which character would you pick?

I find using a single character "too cute". As I see it there are four possibilities:

• The current one, i.e. repeating the basicstyle=\ttfamily all the time.
• Switch so that normal listings have basicstyle=\footnotesize\ttfamily - and nothing for the inline ones.
• Define a new normal command, even though it requires quoting of some special symbols.
• Have different settings for inline and normal listings!

The last one seems to be possible as follows (there might be a simpler solution): Remove basicstyle=\footnotesize\ttfamily as a general setting, and instead have all used languages (modelica, grammar, C, fortran77) define it.

And then define a dialect: \lstdefinelanguage[short]{modelica}{basicstyle=\ttfamily, ...} and use that as default language.

As far as I recall the long listings always specify a language (without "dialect") - so it should work, and be clear: we would have \lstinline!...! and \begin{lstlisting}[language=modelica] I could do that. The only downside is some copy-paste in the preamble.

[henrikt-ma]

This is beginning to sound like a nice solution. To me, the main drawback with the single character markup is that it makes it hard to automatically find and replace all occurrences the day we don't like it anymore. A macro name is much easier to find, and combined with a delimiter that is rarely used in the language, it becomes easy to identify the piece of inline code.

Would there be a problem to define a new environment that just sets up lstlisting with with the right options?

[GallLeo]

I think this would be great. Hans, could you prepare the preamble?

We finished the editing. Currently we are fixing some stuff in the non-normative text (code should be visible there as well, but we have to interrupt the \emph{} environment in all places). Push should be possible, tomorrow.

[HansOlsson]

I think this would be great. Hans, could you prepare the preamble?

That is done now. (And I verified that begin{lstlistings} always specify language.)

[henrikt-ma]

Can't the non-normative text be addressed better by using an environment instead? It seems odd to me that these large chunks of text are marked using {{\emph}} anyway. With an environment, I'm hoping that there wouldn't be a need to interrupt it for injection of inline code.

I realize that the use of an environment would make most sense if the non-normative text was standing as separate paragraphs instead of being embedded in normative paragraphs, but I would actually think that this would improve readability and separation of normative and non-normative content in general.

[HansOlsson]

Can't the non-normative text be addressed better by using an environment instead?

I agree that would be good, and it would indicate the intent.

I even considered that originally and then stumbled on https://github.com/brucemiller/LaTeXML/issues/874 and didn't go back after the bug was resolved.

I realize that the use of an environment would make most sense if the non-normative text was standing as separate paragraphs instead of being embedded in normative paragraphs, but I would actually think that this would improve readability and separation of normative and non-normative content in general.

Agreed. There might be some non-normative texts that don't work as separate paragraphs, but perhaps they should be part of the normative text - or just removed:

The first example I found was: "The right-hand side expression in a binding equation [that is, expr] of a parameter component and of the base type attributes [such as start] needs to be a parameter or constant expression." The first can be removed without losing anything, and the second changed to a normal parenthesis.

[GallLeo]

Not sure how to get the task finished now. I thought the idea was to not change any formatting compared to the Word document, other than code highliting.

Should we stop interrupting \emph and wait for you defining an non-normative environment?

[HansOlsson]

Not sure how to get the task finished now. I thought the idea was to not change any formatting compared to the Word document, other than code highliting.

Should we stop interrupting \emph and wait for you defining an non-normative environment?

I would say add the emph so that the document becomes ready and looks as similar as the original as possible; similarly tables are still overused in the new document.

We can then improve the structure - in particular when it involves moving texts (and both replacing tables with something simpler and placing non-normative texts as separate paragraphs involves moving texts).

[henrikt-ma]

Right, if that was the easier thing to do. I just thought that it might be at least just as easy switch to an environment when having to visit all the places of inline code in the non-normative sections anyway. Clearly, this is not the time to switch to the solution that would require more time to implement.

[HansOlsson]

https://github.com/modelica/BackOffice/issues/14#issuecomment-465558790 noticed that some parts (specifically in section 17.1) of the new PDFs were less clear than the Word-document, due to difference in paragraph skipping and indent.

Looknig more closely it seems that the Word-document wasn't internally consistent, and that section was one of the exceptions as Chapters 16 and 17 (and text before Table-Of-Contents) have parskip without indent; but large parts of the rest seem to have indent without parskip. In some cases both variants were mixed in the same sub-section e.g., 18.6.2, and at least I couldn't understand why.

I assume we don't want such mixing, and it seems parskip without indentation seems the best for this kind of document; and assuming others agree we should just use it consistently.

[henrikt-ma]

Yes, parskip without indentation is my preference as well.

[GallLeo]

Regarding the formatting of inline code, I pushed the current status to https://github.com/GallLeo/ModelicaSpecification. Remaining issues on Backoffice side:

• [x] Fix some of the \emph
• [ ] Check/diff through the changes in order to avoid unwanted changes

[HansOlsson]

@GallLeo Any update? The next design meeting is approaching fast.

I understand that you have had some other things to deal with, and that you did work on it latest last week.

[GallLeo]

@HansOlsson Please review my pull request. Inline formatting should now look about the same as in Word.

Would be good to take another round for using the new example and nonnormative commands, but this turned out to be more manual work than expected.

[HansOlsson]

Language group:

Main tasks done. Remaining tasks should be separate tickets.