Decimal divider localization issue

Bug
1

I am using a project that on reopening changed it’s dimensions. It is width=“1280” height=“720”, but in the project viewer it is now scaled and i can’t see the upper right corner of the image any more. The file still says that it has the correct size. I think the problem arose when I added high resolution still images to the video. As you can see on the screenshot, the frame of the “Size and Position” filter has an offset to the actual border of the content, same is true for the text in the project. (This is not in GPU Processing mode).

Screenshot from 2017-01-26 00-19-01.png1062×480 369 KB

Question: Is there a way to salvage this project or do I need to start over, presumably this time first downsizing the still images to the format of the video, so that the bug is not triggered.

2

If this is happening to the clip itself without any filters, try checking the project’s .mlt XML or the resolution listed in the properties. Open your project in a text editor like notepad++ and check at the top what resolution it says within the profile description tag. There should be “width” and “height” values, and you can change them back to what your resolution should be.

However if this is only because of the size and position filter, just disable and/or delete it and add it back.

3

Here is what I did, probably the bug will only manifest if you are running Shotcut on a system that has commas as decimal dividers.

  1. make a new file
  2. open other, pick a solid color.
  3. add it to the playlist
  4. add it to the timeline
  5. put a text filter
  6. make text smaller and move it to center
  7. save.

Now open it again. Shotcut will tell you the file is damaged and needs repair.
a) Say yes. File will open but text is gone, looking at the properties it has been moved off screen.
b) say no. File will be as you left it. No problem.
test - Repaired.mlt (4.0 KB)
test.mlt (4.1 KB)

4

Are attaching .mlt files of any help without the video source?

5

Absolutely. The bug doesn’t need any video to be triggered. Just a black matte and some text is enough.

6

No problem here. Opened just fine and text is where I left it.

Nope.
Your .mlt opens as a 1920x1080 project with no text filter .
Opening the file in notepad as suggested by Lauren shows ;

7

Please do a quick file compare of the test.mlt and test - Repaired.mlt. You’ll see that the good file test.mlt has a text filter applied to the matte with the property <property name="geometry">30,78%/18,43%:34,64%x52,78%</property> the automatic repair changed this into <property name="geometry">30.78%/18.43%:34.64%x52.78%</property> The decimal divider has been changed. Loading the repaired file will make the numbers too high, because my Shotcut ignores dots in the numbers, turning 30.78% into 3078% which then seems to get evaluated as an absolute number rather then a percentage.

I am concluding this very much looks like a i18n problem in the code with decimal dividers. In the .mlt XML numbers should always be stored in the same format, (probably the anglophone dot a a decimal divider) while only the GUI should localize it to whatever format the user is having on her/his system.

I am using an English language OS, but with a German numbering, so my decimal divider is a comma.

8

Well, both files have a text filter applied as you can see in the .mlt XML. I think you haven’t looked hard enough. :stuck_out_tongue:

<filter id="filter0">
  <property name="argument">Remote</property>
  <property name="geometry">30,78%/18,43%:34,64%x52,78%</property>
  <property name="family">Anaheim</property>
  <property name="size">570</property>
  <property name="weight">500</property>
  <property name="style">normal</property>
  <property name="fgcolour">#ffffffff</property>
  <property name="bgcolour">#00000000</property>
  <property name="olcolour">#ff000000</property>
  <property name="pad">0</property>
  <property name="halign">center</property>
  <property name="valign">bottom</property>
  <property name="outline">0</property>
  <property name="mlt_service">dynamictext</property>
  <property name="shotcut:filter">dynamicText</property>
</filter>
9

The decimal as a comma problem is a known error that has a few workarounds and there are still some problems with it. There are several github issues regarding this, some closed but some still open too, just look here.

I would say if there’s a way to change your german number localization so that all of it is English it would work, but I know not everyone would be willing to do that. Manually editing every single .mlt file you work with from now on would be pretty tedious and unreasonable too. Otherwise I cannot say when all of these problems will be fixed…

10

It works with the comma for me (as long as I don’t exchange my files with someone who has a point as a decimal divider) but the automatic “Repair” of the file destroys it.

11

Yes, but NOT when open in Shotcut, was my point.

I’ll leave it here as it seems to be a local issue for you.

12

It is a problem to use a mixed mode like this. It is difficult to make the cross-platform technologies read and use that level of detail. For example, the XML repair tool is using the decimal point for the name of the region - not reading the decimal point setting directly. This was actually to fix a bug on macOS that did not quite work right and then required a different change. So, I can change that back for Linux and Windows to read the actual decimal point setting. However, the APIs MLT is using will, on Windows, write using the current decimal point setting but then declare LC_NUMERIC based on the name of the region. In any case, yes, I recognize there are problems, but it is a challenging problem to get correct across multiple operating systems let alone people using a mixed mode like this. This may not get a high priority to address with the extremely limited developer resources available to the project. (No one seems to want to help with the code, and I have very little time anymore.)

13

Wow, that’s a very interesting design choice. I would have thought it’s the best to leave localization out completely of the files and only interpret it in the GUI, rendering the numbers depending on the user’s locale.

In the file comparison before/after the repair you’ll see that both have the LC_NUMERIC=“de_DE.UTF-8”, how comes the commas get converted to points then?

Sad to hear about your limited time. I know what you are talking about. Shotcut is an amazing project, I hope there are some gifted programmers joining you.

14

Additional information (not sure if any more relevant):
I get
[Info ] <Application::Application(int&, char**)> locale = QLocale(English, Latin, UnitedStates)
...
[Debug ] <MltXmlChecker::MltXmlChecker()> decimal point '.'
when I launch Shotcut. Never the less the files created with that Shotcut have LC_NUMERIC="de_DE.UTF-8"

15

The way things work her changed a little in v17.02. Any further posts in this thread should avoid using v16.01 and specify version used.

1 Like