christianvoigt/argdown

Improve charactersInLine estimation of line width

6-AND-9 opened this issue · 5 comments

Hi again,

I am sorry for bombarding you with issues, but I really dived into Argdown and want to learn it thoroughly.

I am trying to define the charactersInLine setting for statements. I do this:

===
model:
    removeTagsFromText: false

title: a title
selection:
    excludeDisconnected: false
    statementSelectionMode: not-used-in-argument

group:
    groupDepth: 5
    minWidth: 0
argument:
    minWidth: 0
statement:
    title:
        charactersInLine: 50
    text:
        charactersInLine: 150
    

===

But it doesn't work. The node size stays the same, which is terrible for nodes with huge content as they spread downwards and enlarge the map needlessly towards the bottom. Dagre map looks even worse. You can see the example screenshots below.

Am I doing something wrong?

Dagre example
Vizjs example

Hi, bug reports are really helpful, so no need to apologize for that (I am at the moment pretty occupied in "bundling hell" trying to fix webpack issues for argdown-vscode, so I do not have much time for bug fixes, but sooner or later I will get to it).

The settings you want to use are settings of the DotExportPlugin (or the Dagre plugin). So you have to change your code like this:

===
model:
    removeTagsFromText: false

title: a title
selection:
    excludeDisconnected: false
    statementSelectionMode: not-used-in-argument

dot: # this is the change
  group:
      groupDepth: 5
      minWidth: 0
  argument:
      minWidth: 0
  statement:
      title:
          charactersInLine: 50
      text:
          charactersInLine: 150
    
===

At the moment the "width measurement" using charactersInLine seems to be underestimating the string width (in my test the text was wider than the node). I will rename this issue accordingly. It would be great if you could report your test results here.

If you have the same problems you might be better off using measureLineWidth.

In my tests the problem only occurs with long titles. Statement text and argument text is working fine. The problem is caused by the bold text. This is confirmed if you use [s1]: **my long long long statement text** to make the statement text bold.

Hi Christian,

Thanks for renaming the title.

Yes, the main problem seems to be caused by bold text. Also the text justification seems weird i.e. there is none. Each row starts and ends in a unique position (see the screenshot). I don't know if there is a way to specify justification (I'll search the manual, but 'justified' delivers nothing in the search), as every text in every node seems wild currently.

I guess these are some issues on your side that you'll fix eventually.

For now I got it a bit more appealing by using measureLineWidth. Thanks for the tip about `dot:', though.

Vizjs example

wow, that is wild. To see what is going on there I would need to have the Argdown source code. But it is not my aim to support giant amounts of texts in single nodes. Viz is not good for layouting text (in theory Dagre is better, but nobody is actively developing it at the moment).

In general, if you want to customize the look of your map drastically, I would always recommend to export your map to GraphML (after you have finished it) and manually customize it in yEd.

I took another look at this. The "node width" is determined in two steps: a) insert line breaks every x characters (or if a certain width is reached), b) determine the width of the node box surrounding the text, based on the longest line of text.

The Argdown plugins only do a), b) is done by the layout engine (Graphviz, or Dagre) and I can not change anything about this.

The issue is caused by b), because Viz.js currently has an issue with measuring text correctly, if the text contains bold, italic or multi-byte characters.

Help is welcome: it would be fantastic if anyone could help out by compiling Graphviz and finding out which libraries are missing in Viz.js (see the link to the issue for further details).

This is issue is also causing #138, which I will reopen until the issue is fixed in Viz.js.