Valentina v0.5.0.0.a locked up in Pattern Properties


Valentina v0.5.0.0.a locks up after clicking Apply in Edit/Pattern Properties/General tab. I’m running Ubuntu 14.04, 65-bit.

I was able to recreate this problem twice, then rebooted, now I can’t recreate the problem.

Could others who have downloaded the latest test build check if their systems lock up too?


I managed to reproduce the problem. Issue #589 was reopened.

The way to reproduce based on your instructions:

  1. Open a pattern.
  2. Generate a layout.
  3. Go back to Detail mode.
  4. Open Pattern Properties/General Info tab.
  5. Edit one or all fields. Press Ok.
  6. Valentina hangs.


Is @Bojan still with us? This issue related to his code.


@slpencer, i know what cause this issue. But i need your advice how to fix it.

The bug happens when a label can’t be adjusted to string size. For example very long string ‘wwwwwwwwwwwwwwwwwwwwww’ doesn’t contains space character and can’t be splitted. So, my question is ‘What to do this such a string?’. I can use method QFontMetrics::elidedText. Or allow a string to go beyond a label rect if all possible adjustments were used and we still can’t fit a big word.

Also i don’t know what to do if maximum possible label height is not enough to fit all rows.

The error lives in methods:

  • VTextGraphicsItem::CorrectLabel()
  • VTextManager::IsBigEnough() (string 603)


Yes, he is. :slight_smile: The reproduction of the problem described in 6 steps does not work for me, it probably depends on the pattern opened. But I understand that entering very long string could lead into this kind of issue indeed.


I will send you @slpencer pattern.


You don’t need even 6 steps.

  1. Open a pattern.
  2. Open Pattern Properties/General Info tab.
  3. Edit any field with very long string. For example ‘wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww’.
  4. Press OK.

Your algorithm ignore the fact that in some cases don’t enough space to make a rectangle even bigger and we can make font size smaller. This call an infinite loop.


@slpencer, i and @Bojan are waiting your answer. :wink:


Okay, So there are two problems embedded into this one.

  1. Too many rows ® for the label height (H)
  2. Too many characters © for the label width (W)

For each label: Step 1. Count non-blank rows ®. If R=0 then don’t generate that label, exit (skip Steps 2, 3, 4) Step 2. Calculate font size (FSH) using rows ® and label height (H). FSH = (0.75*H)/R This allows 25% label height to be divided between rows Step 3. Calculate font size (FSW) using max characters © and label width (W). Cn = chars in Row n, n in {1…R} C = max(C1…CR) FSW = W/C Step 4. Calculate final font size (FS) as minimum of FSH and FSW. FS = min(FSH, FSW) Calculate row placement using H/R This method allows all characters to fit in the label, with space between rows.

Note: Possible Row values are different for each label:

Currently for Pattern Properties (used in Pattern Label) there are a maximum of seven rows of data in the label, minimum of 0 rows (none of the fields are required), so R is an integer in {0…7}. Where R = 0, don’t print/generate the label.

Currently for Pattern Piece Data (used in Detail Label) the number of rows of data in the label is variable, with a minimum of 2 rows (Letter and Name of Detail are required). There should probably be a maximum number of rows of material, enforced during data entry, so as an arbitrary limit we could implement a maximum of 10 rows (for quilters). :nerd: So R is an integer in {2…12}. The Detail Label is always printed/generated.


@Bojan did you read the answer? I need this fix to be able to continue redesign seam allowance tool.


Sorry, I didn’t see Susan’s reply until today. There is one problem I see with her algorithm of calculating font size, which is, what happens if the font size falls below a minimum reasonable size for a normal person to see. I mean it’s possible to set font size to 1, but it’s useless because nobody can read it. How do we handle these cases?


@Bojan, It’s up to the designer to adjust it to what they believe is a reasonable size! If the code works and doesn’t crash then we’ve provided a good tool to allow the designer do what they want.


OK then, thanks for the explanation. I will do that.


I understand your point but see an issue. Because you do not propose any restrictions for minimal font size this can theoretically cause a crash on Windows. We already had two issues tickets related to this behaviour. Windows can’t render very small font sizes.

I think we will not go anyway without some restrictions. One or another way, but users will not be able to read a label.


okay then, what do you suggest would be a good minimum font size?


Any font size will not be good enough for me. Because i afraid case where a font is already minimum and a rect size is already maximum, but we still do not have enough space for all strings and words. See my first proposal.

For fixing width - QFontMetrics::elidedText. For fixing height - ignore strings that go beyond max height.

If something can happen it will. And i’d rather want to be sure we will not return to infinite loop.

So, i support your proposal, but want cover all possible cases.


We must assure maximum automated behavior with generating the Detail pieces:

The labels and fonts must scale with the size of the label each time the pattern is generated. Recalculate the detail pieces, labels, and font size whenever the measurement file is changed. Do not use the previously generated or a default font size.

When the label font size is less than the minimum font size, then select the minimum font size & the elided text rule is invoked for fixing width & ignore strings past the max height.

FS = label font size minFS = minimum font size FSH = font size to match height FSW = font size to match width FS = max(minFS, min(FSH, FSW))

So we need to define the minimum font size to prevent crashes.


Maybe font size 5 or 6?


Roman, I think your suggestion is good. Just one question: ignore strings that go beyond the max height means that if user produced 8 lines of text, but only 6 lines of text fit into the label, we just show first 6 lines and ignore the last two?

And I think the algorithm Susan outlined in the last post should finally work without getting into infinite loop.


Do you see better alternative? Yes, ignore. We could additionally produce warnings as you suggested in private discussion.