Printing is a different media. The web has grappled with this since…ever.
Different media, different style that should be used when ‘displaying it’…
Limitations of one media (paper here) ought not to dictate policy for another media…
Whatever you mean with this: the problem I described is real.
I’ve requested more then once do do something with the print function, so that we have better control over it.
Best would be of course a true WYSIWYG mode.
I have indeed such well fine tuned Pages (office forms for my business), that fit exactly on a printed sheet. Has cost me some dozen rounds of try & error to get everything on that sheet. And there was links …
You can’t imagine how often I was on the edge to cry in frust and anger!
You would never expect, that if you change an Object’s name, that it would affect another Object in a way, that will cost you hours at some other day!
I am not minimizing your pain at all.
I am simply saying this ought to be fixed by applying a different style for printing (in code) and not force the same design in the UI just for the sake of print media…that’s all
Yeah, that’s right, I know.
I’ve written about that more then once over the year.
But I can’t see how it would help in this case.
Even if you have a different style for printing - at some point in time it is fine tuned so that everything fits exactly on the sheets you print. Now becomes one text line longer, because the child Object of a link was edited.
What do you think should happen in such a case?
two options: for printing, allow either wrapping in cells, or, an elipsis to prevent overflow…
or, having constrained media like printing or mobile in mind, have ‘short version’ for attributes (relations)…
this is something for the far far future, when already the space ship Enterprize flies, or so.
I begged again and again for stinky normal standard 08/15 WYSIWYG for over a year and it is still not there; not even on the roadmap.
And now you come with additional options, in different styles and this and that …
the App is simply much too young, it’s development has started 2018 (quasi yesterday!) – you can’t seriously expect that it’s already developed enough to print what the user sees AND has even additional options and so on!!!11!
Still looking forward for this QoL enhancement to be added
Even just ellipsing at a later letter would be great
Just created my first long title and realized how annoying this is! Can’t wait to see what comes of this 
And the way ellipsing is done, you can’t even change it using CSS, for example.
Please add an option to disable or change the number of characters. If I’ve created a big title, it’s because I want to show the big title
Not sure when this entered planning, but I am PUMPED for this 
I do like the idea of this being something that is manipulatable in CSS, although that means this feature wouldn’t make it to mobile. I wonder what the best way to implement it will be 
I see your post says this has entered planning, is this being worked on? I’m so curious because I didn’t see it in the roadmap. This has got be one of the single biggest pains I’ve had with AnyType, I encounter this ellipsizing bug on a regular basis.
I tried one workaround mentioned elsewhere (to use the / command and then link) but that really is awkward and interrupts the good workflow. I don’t know any other application that force truncates links like that. I’ll be so very happy when it’s fixed.
Typically, only larger projects or feature requests are added to the roadmap.
Regarding the request, we don’t plan on providing an option to disable it at the moment. However, we will increase the character limit significantly.
Significantly = from 30 to 300
Huge improvement in usability and usefulness!
Wait, I didn’t realize this was happening in 0.51 that released today? This is so exciting!! Now I can make my object titles as stupidly long as I want 
Yeah, the biggest change out of the whole release, lol)
Should this be changed from Planning to Implemented, or is there more to come?
Implemented I think.
The recent AnyType updates made link text much more useful and visible by extending the amount of text that appears before the ellipsis cuts it off.
However, it only seems to work for inline links (those created with the @ symbol). If you use a / to create a block link, you will still lose whatever text is in that link name when it gets the short truncation with the ellipses.