[bug] \n Displayed in Cable Notes

[davidrea]

Adding a \n escaped character works to insert a line break in:

• Connector notes: entities
• Connector type: and subtype: entities

But the \n escaped character is printed in cable notes: entities:

Source for above:

connectors:

  P1:
    type: Socket housing
    subtype: Molex SL\n50579406
    pinout: [VDD, SWCLK, GND, SWDIO, NRST, SWO]
    notes: "Terminal: 16020086 or equiv."

  P2:
    type: Pin header
    subtype: Adam Tech\nBHR-20-VUA\nor Equiv.
    pinout: [VCC, VCC (optional), TRST, GND, TDI, GND, DIO/TMS, GND, DCK/TCK, GND, RTCK, GND, SWO/TDO, GND, NRST, GND, NC, GND, NC, GND]
    notes: Solder wires to pins,\nheat shrink individually

cables:
  W1:
    gauge: 24 AWG
    length: 0.2
    wirecount: 6
    category: bundle
    colors: [RD, GY, BK, GY, GY, GY]
    notes: Stranded,\nHeat shrink bundle 2 plcs
    # ^^^ this line contains printed \n ^^^

connections:
  -
    - P1: [1, 2, 3, 4, 5, 6]
    - W1: [1, 2, 3, 4, 5, 6]
    - P2: [1, 9, 4, 7, 15, 13]

[davidrea]

Just tacking onto this, \n escaped characters also appear in HTML BOM:

[formatc1702]

Thanks for the heads up. I can't look at the issue in detail now, but I can offer solution that (IMHO) is more elegant than using \n for new lines, since YAML supports multiline strings natively.
The code below fixes both the rendering and BOM issues:

connectors:
  P1:
    type: Socket housing
    subtype: |
      Molex SL
      50579406
    pinout: [VDD, SWCLK, GND, SWDIO, NRST, SWO]
    notes: "Terminal: 16020086 or equiv."

  P2:
    type: Pin header
    subtype: |
      Adam Tech
      BHR-20-VUA
      or Equiv.
    pinout: [VCC, VCC (optional), TRST, GND, TDI, GND, DIO/TMS, GND, DCK/TCK, GND, RTCK, GND, SWO/TDO, GND, NRST, GND, NC, GND, NC, GND]
    notes: |
      Solder wires to pins,
      heat shrink individually

cables:
  W1:
    gauge: 24 AWG
    length: 0.2
    wirecount: 6
    category: bundle
    colors: [RD, GY, BK, GY, GY, GY]
    notes: |
      Stranded,
      Heat shrink bundle 2 plcs

connections:
  -
    - P1: [1, 2, 3, 4, 5, 6]
    - W1: [1, 2, 3, 4, 5, 6]
    - P2: [1, 9, 4, 7, 15, 13]

I will still keep this open, but I'm unsure whether converting \n to newline is something that should be implemented if there is a more standard way in YAML.

[formatc1702]

Looking at the Flow Scalars section on yaml-multiline.info, it seems that not converting \n into a newline for plain strings is the expected behavior. I can't say why it does work in connectors and not in cables... would need some time to do more testing.

I can confirm that, putting the cable's notes info in double quotes does convert \n into the desired new line, matching the behavior described in the link above.

[kvid]

WireViz does not interprete the \n escape sequence, and sends it untouched to the output files, including the .gv file that is read by Graphviz. However, Graphviz does interprete several escape sequences and that is why the \n split the line in connector attributes that use shape=record. The wire nodes are formatted with HTML and the \n escape sequence is apparently not interpreted then (<BR/> is used to break the line in HTML).

[kvid]

When testing the better approach with multi-line strings in YAML, I became aware of a minor inconsistency about horizontal alignment that I raised as the new issue #90

[davidrea]

Thanks for the feedback on yaml, I wasn't aware of that! I'll switch to using the standard multiline input on this diagram.