Yes - there is a hard limit of 5 lines of text in Pikchr. (In legacy PIC, the limit was 3 lines.) Furthermore, Pikchr does not provide convenient shorthand notation for generating the relationship lines. ERDs were not a think decades ago when PIC was designed.

This is a kludge, but it might work for you:

down
#somewhat=0
somewhat=-.05
Gt:"line 1"; move somewhat
"line 2"; move somewhat
"line 3"; move somewhat
"line 4"; move somewhat
"line 5"; move somewhat
"line 6"; move somewhat
"line 7"; move somewhat
Gb:"line 8"; move somewhat
zzz=(Gt.nw.y - Gb.sw.y)
Bigbox: box height zzz with .nw at Gt.n

  down
  #somewhat=0
  somewhat=-.05
 Gt:"line 1"; move somewhat
 "line 2"; move somewhat
 "line 3"; move somewhat
 "line 4"; move somewhat
 "line 5"; move somewhat
 "line 6"; move somewhat
 "line 7"; move somewhat
 Gb:"line 8"; move  somewhat
 zzz=(Gt.nw.y - Gb.sw.y)
 Bigbox: box  height zzz with .nw at Gt.nw

thanks. i'll play around with that.

Hi,

I'm interested in why this hard limit exists. I've not bumped into other limits of this type with Pikchr, but I run into this one frequently. If it was because some limit in the code was needed, maybe it could be set substantially higher to allow more use cases? In my case, that'd be a paragraph or two of text.

Thanks,

Jim

I also run into this particular limit relatively often.

An increase of this limit would simplify a lot of my pikchr diagram.

With more than 5 labels, it is unclear what the "above" and "below" modifiers should mean. It was dodgy enough going from 3 labels to 5. Going to an arbitrary number makes "above" and "below" really difficult to understand.

The original PIC spec only allowed 3 labels and the meanings of "above" and "below" where clearly defined. How do you propose to change the PIC language to accommodate an arbitrary number of labels?

The semantics of above/below are a good reason for the limit! Even with the current limit, I find these labels a bit confusing, with sometimes unexpected results. e.g.

arrow "A" "B" above "C" above "D" "E" above

resulting in:

arrow "A" "B" above "C" above "D" "E" above

I don't have a well-thought-out proposal yet, though stepping back, I'd offer that there is a use case for some way to achieve multi-line text efficiently. The current text object seems, AFAICT, to just be an invisible anchor on which to hang annotations in the usual way. Perhaps there could be a different, expanded text-type object (blocktext or something) that could be a container for multi-line (i.e. \n aware) text, with some accompanying block text appropriate modifiers such as rjust etc. Not too unlike <pre> in HTML...

This would be a standalone object, not an annotation, and would still require composing with some other object to achieve things like the original ERD example that started this thread. But this would be composing two relatively simple objects. And such an approach wouldn't require further complicating above/below nor cause backwards compatibility issues.

You could always try something like

A: [down
    box "Title" big bold "This is a" ljust "Multiline box" ljust "which does need" ljust "a small amount" ljust fit invis
    box with nw at 10px n of last.sw same "of special treatment" ljust "but in a way that" ljust "is very easy" ljust "to automate" ljust fit
    box same "No clever tricks required" above "the end" rjust below]
B: box at A wid A.wid ht A.ht
dot at B.e " .e" ljust fill red
dot at B.sw ".sw  " rjust fill red 
arc -> from B.nw to B.w color green
dot at B.nw ".nw" ljust above fill blue
dot at B.w ".w  " rjust below fill blue
arrow from 0.5<B.ne,B.e> go right
circle rad 3px at last
arrow from 0.8<B.e,B.se> go right
box wid 5px ht 5px at last