Skip to content
This repository has been archived by the owner on Jul 29, 2019. It is now read-only.

Width constraint does not break words... #3185

Closed
jmvenancio opened this issue Jun 18, 2017 · 10 comments
Closed

Width constraint does not break words... #3185

jmvenancio opened this issue Jun 18, 2017 · 10 comments

Comments

@jmvenancio
Copy link

I set the widthConstraint to maximum: 300 and minimum: 300.

This is what happens if I write a word that has a bigger "length" than 300.

image

Is there anyway to overcome this problem?

Thanks in advance!

@wimrijnders
Copy link
Contributor

This is how the handling of a single, long word works at the moment. It gets put on a line by its own and the widthConstraint.maximum is broken.

I have the following questions:

  • Is there a real-live use case for this? Does it actually happen that such a long word is present?
  • What would you expect to happen? Is the second image perhaps a representation of what you would expect?

@bradh
Copy link
Contributor

bradh commented Jun 19, 2017

An overflow might make more sense.

@wimrijnders
Copy link
Contributor

By coincidence, I'm actually working on label break-down into lines, see #3171.

This issue made me ponder a bit; I sort of came to the conclusion that if widthConstraint.maximum is defined, it should be respected always. So really, big words should just be broken into lines always.

Here is some test output, what do you think of following?

Without width maximum:
untitled2

With width maximum:
untitled

@wimrijnders
Copy link
Contributor

Is there anyway to overcome this problem?

To answer your question, the only way around it now, is to shorten the label yourself.

Otherwise, wait for the fix as described above to be released.

@jmvenancio
Copy link
Author

Thank you for your answer.

That behaviour is what I was expecting. Do you know when will it be the next release? Should I put my effort on breaking words myself or should I wait for the next release?

Answering your questions:

The future users of my project can do whatever they want... So, although it is not likely to write a 1000 letters word, they can do it. And of course the word should be broken to the next line (and perhaps adding a - in the previous line, even if it does not respect the language rules) what do you think?

@wimrijnders
Copy link
Contributor

Do you know when will it be the next release?

It is planned next weekend (24 jun 2017). However, this will not be in it, it's too late to do the full review cycle.

Should I put my effort on breaking words myself or should I wait for the next release?

If you need it short term, then yes, put the effort into it. At the earliest, the release it will be in will be done in more than a month.

...what do you think?

I agree, see my thoughts above. Big words should be broken always.

@jmvenancio
Copy link
Author

Hello, can you tell me if there is any progress with this issue?

@bradh
Copy link
Contributor

bradh commented Jul 10, 2017

@jmvenancio There is an open pull request at #3228 that you could test if you're comfortable with github / git and able to rebuild.

@jmvenancio
Copy link
Author

Actually I do not know how to rebuild it. But if someone explain to me I can give a try since I really need this fix.

@bradh
Copy link
Contributor

bradh commented Jul 11, 2017

https://github.com/almende/vis#build provides the build instructions. You need to check out the branch that has the changes - see https://help.github.com/articles/fetching-a-remote/ and do google searches. Sorry that I don't have time to provide step-by-step instructions.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants