I thought I fixed the split-word thing ages ago? That was the only actual “bug”, right?
But I really can’t change it like you suggested - honestly, to change a function so that it suddenly behaves entirely differently when one of the parameters hits a particular floating-point value just isn’t a reasonable thing to do!
As I said, the “bug” is still on the last tip… And for me, the random height justification from here, which should be like here, is also a bug. I just cannot imagine any graphic designer wanting something like that happening in an application !
OK, I agree with that. So, the problem is there is still no function of the class Graphics allowing to draw a text without any new line character in a box, with new lines added automatically, like you can find in every notepad-like application, or like the behaviour of text in web pages.
Maybe the solution would be to add a new function to draw text, like a justified version of drawMultiLineText ?
Anyway, I’m stopping there. I have created my CustomLookAndFeel class a long time ago now, that works for me. I thought you would find annoying like me to have a Label behaving in a way which would put every graphic designer of the world in the same state of mind than in front of a webdesign using Comic Sans MS everywhere.
huh? Sorry, but what height are you talking about? And I much prefer the first version (with the equal length lines) than the one you seem to be saying is better (??)
Seriously ? I mean, I may be wrong, but have you ever seen somewhere any text, in an application, in webdesign, in CAO, which is justified this way, with equal length lines ? This the FIRST time I have ever seen something like that. I’m not even sure the option to justify the text this way exists in any design application from Adobe.
I agree it may look better in the context I have displayed (one label with all the text centered), but in other contexts, it may be a nightmare. I have developed a while ago an application to create user documents, displaying combinations of Labels, justified on left, and objects such as tablatures or guitar chords. The objects were centered, and the text was ugly, because this behaviour on text justified on left had put large empty spaces on the right of each labels, and sometimes it added extra lines which were unnecessary.
If someones wants the lines to be of an equal width, the only way which makes sense to do that is to reduce the width of the container ! Having the new lines characters put randomly sometimes to have the lines of equal width, and sometimes not, with a container having a large width, is just non-sense, and can break the design of a page according to its content !
At least, such an option should be optional in my opinion.
One thing to notice is Wolfen is French, and rules of “line break” are different in Français compared to in English.
For a French guy, cutting words at random is a crime. There are strict rules (cut at whitespace, if it’s not possible for alignment reason, cut at syllable boundary but add a “-”(with exceptions, as usual, in French) so the reader knows the word is going on on the next line).
So grammatically, the former screenshots are bad in French (probably ok in English) while the second are correct (but horrible in design).
Cutting word is also something that’s language dependent, and the Juce algorithm is naïve. I wonder if you cut a german word like this, you might actually create a completely different meaning (2 words out of a “complex” almagamation-word).
Anyway, the real solution would be to use run-time “overrideable” rules for word cutting, and such rules ©should be explained in a translation file.
Something like:
en.txt
[...]
word-cut: anywhere >7
[...]
fr.txt
[...]
word-cut: syllable,double-letter,add-minus >7
[...]The algorithm would then call an explicit method to parse the “word-cut” directive, and apply the algorithm depending on the language.
Hello X-Ryl669 
You mean in English it is common to cut a word in the middle to add the new line ? I don’t want to go into the rules about the use of “-” here, it would be language dependant as you say
Anyway, the two issues I have been talking about are the following :
I don’t think there is something here related to the fact I’m french :mrgreen: It’s just the way everything in the world is working for me, from Microsoft Office to web pages, Adobe Creative Suite, even the textbox editor I’m using right now to write this message ! Have you ever seen a graphic designer doing typography and cutting words in the middle ???
Yes. All the time in text writers software (Latex, Acrobat, Pagemaker, Word, etc…), but you might not have seen it because you’re using it in French, or without “Justify” mode (left justification does not cut words), or without fixed width output (like a column layout). Justifying text is more complex than it seems, and most algorithm have specific parameters than might be strange at first (like the maximum space size allowed between words, the maximum number of characters allowed before cutting, etc…)
Open any PDF file with columns, you’ll find word cut everywhere (with or without ‘-’ depending the typography rules for a specific language)
Anyway, your particular fix is not good, since it’s not what the author intend, and because it would break the existing code from all the Juce users.
You might provide a better fix that’s checking up some run-time set variable so the behaviour, by default, follow the exisiting code, but you can tweak it to your need if you want too.
Provided it’s generic enough to plug new cutting algorithm, I think Jules will accept this in the code.
[quote=“X-Ryl669”]One thing to notice is Wolfen is French, and rules of “line break” are different in Français compared to in English.
[/quote]
As it happens, the rules actually differ for English depending on dialect. American English line breaks works differently to British English. I doubt most people would spot it, at worst they’d just assume a clumsy hyphenation algorithm, but there are differences.
Despite working in a thoroughly international department I generally manage to avoid dealing with language and text flow issues, but I try to stay aware of them in case I do need to build code for Japanese users, for example. My sense is that the Look And Feel class needs a peer for handling all aspects of text flow. Acceptable hyphenation and full justification rules differ so much from region to region (and can possibly even differ within fields, I.E. law or chemistry) that it might be better just top give developers complete domain control over text flow if our situation requires it. (Which is not to argue that some common general use models should not be built in).
Perhaps if Jules sees a path here that he is comfortable with, a better discussion might be what string manipulation tools people would want over and above the default ones so that writing text flow algorithms is not prohibitively complex.
I got that 
[quote]You might provide a better fix that’s checking up some run-time set variable so the behaviour, by default, follow the exisiting code, but you can tweak it to your need if you want too.
Provided it’s generic enough to plug new cutting algorithm, I think Jules will accept this in the code.[/quote]
Yes, I think the justification algorithms need more tweaking parameters…
[quote]Yes. All the time in text writers software (Latex, Acrobat, Pagemaker, Word, etc…), but you might not have seen it because you’re using it in French, or without “Justify” mode (left justification does not cut words), or without fixed width output (like a column layout). Justifying text is more complex than it seems, and most algorithm have specific parameters than might be strange at first (like the maximum space size allowed between words, the maximum number of characters allowed before cutting, etc…)
Open any PDF file with columns, you’ll find word cut everywhere (with or without ‘-’ depending the typography rules for a specific language)[/quote]
Well, even in english, I still think that any algorithm shouldn’t cut words randomly. Jules’ one cuts words even with left Justification. And it would be a little more understandable with a small width, but here I’m talking about large widths.
However, it may be possible to specify “zero-width spaces” in a word to tell the renderer it can cut the word there if it needs. I think the user specification of the thing is the way to go. I have used LaTeX to write english articles for ages, and I can’t remember of any multicolumn PDF I have created having word wraps in the middle of words randomly (the compiler uses hyphenation tables instead).
Some information on the subject :
http://en.wikipedia.org/wiki/Hyphen
http://en.wikipedia.org/wiki/Justification_(typesetting)
http://en.wikipedia.org/wiki/Word_wrap
http://en.wikipedia.org/wiki/Zero-width_space
http://en.wikipedia.org/wiki/Non-breaking_space
So, I have not found yet any proof that it is forbidden to put word wraps randomly in the middle of words in English for small columns. But some things are sure :
[quote]Despite working in a thoroughly international department I generally manage to avoid dealing with language and text flow issues, but I try to stay aware of them in case I do need to build code for Japanese users, for example. My sense is that the Look And Feel class needs a peer for handling all aspects of text flow. Acceptable hyphenation and full justification rules differ so much from region to region (and can possibly even differ within fields, I.E. law or chemistry) that it might be better just top give developers complete domain control over text flow if our situation requires it. (Which is not to argue that some common general use models should not be built in).
Perhaps if Jules sees a path here that he is comfortable with, a better discussion might be what string manipulation tools people would want over and above the default ones so that writing text flow algorithms is not prohibitively complex.[/quote]
+1
I’m just passing by trying to develop my first project with JUCE.
[quote=“jules”]
There’s nothing actually wrong with the algorithm, but looking at it again, the tolerance for word-length is probably a bit conservative, so I’ve tweaked the number slightly to make it look a bit further for whitespace before giving up, which will probably avoid edge-cases like this one.[/quote]
Please, note that words of the discussed legnth are the normal case in several languages, but not edge cases. You should always have in mind, that you must not make any asumptions about any language. Note that English is a not the best example for making design decitions, as it
[list]
[] has a poor character set (Restricting the framework to UTF seems a good idea to me),[/]
[] has a simple grammar (which is often oversimplified)[/]
[] has many short words,[/]
[] has a fixed word order[/]
[] has simple plural forms[/*][/list]
For the last tree could be solved with an open mind:
[list]
[] You could use hyphenation e.g. TeX http://tug.org uses a simple algorithm. As this algorithm could be externalised it can be used in layout algorithms in order to proviede further solutions.[/]
[] Printf-like string handling with positional parameters can solve the word order problem which cannot be solved by C++ stream like syntax.¹[/]
[] GNU Gettext has solved the plural problem. All alternative C++ solutions I know of (wxWidgets, boost) use the format and algorithms that have been developed with gettext. As far as I can tell from the API documentation JUCE lacks this feature.[/][/list]
Maybe an adapter to the boost classes for Internationalisation would solve this problem.
¹You should rethink your opinion with respect to internationalisation (taken from here).
[quote=“jules”]
I don’t like this method. I don’t use it myself, and I recommend avoiding it and using the operator<< methods or pretty much anything else instead. It’s only provided here because of the popular unrest that was stirred-up when I tried to remove it…[/quote]
I can’t agree more.
<< is bullshit and the (english) people who have thought about it should be condemned to translate all the software that’s written using this horror.
I’ve proposed a typesafe printf compatible for Juce, but it’s not been accepted.
So for now, the String::formatted in Juce is completely broken (the very big issue with String::formatted is that “%s” expect a “wchar_t *” under Win32 while it expect a “char *” with posix, and none of them can accept Juce::String directly), and one has to resort to sprintf hack (or my code).
Thanks, yes, I know all about the problems and solutions… It’s only time and other priorities that have stopped me fixing these things.
@cyril:
I’m not suggesting using << for translated strings. But I’d also never NEVER use printf for translation either.
This is what I’d call bullshit code:
String::formatted (TRANSLATE ("The %s %s is very nice"),
getAdjective(), getNoun())
It’s crap for many reasons, including:
a) If the translated string reverses the order of the noun and adjective, it breaks.
b) The original string is impossible to understand when seen out of the code context (i.e. in a text file of translations)
c) Like you said, there’s the whole horrible issue of what flavour of char pointer the function expects.
d) People always make mistakes with the order of parameters to printf-style commands when there are more than a couple of them
Instead, the best practice is to write it like this:
TRANSLATE ("The %adjective% %noun% is very nice.")
.replace ("%noun%", getNoun())
.replace ("%adjective%", getAdjective())
