Neue Testversion 20.40b6

[Martin Huber]

GUI input fields inconsistency:

It is now possible to use the up and down cursor keys to change the colour values in the colour picker. Great!

However, anywhere else in the GUI this will not work.

You should be able to modify numbers in every text field that contains a numeric value. I just tried a few and didn't find any that didn't work.
But it is not possible to change numeric values with arrow keys in list fields.

For example, I cannot change the position, angle, scaling, etc. with these keys in the layer panel. It also does not work with the tools panel.

As I said, list field don't work because there the arrow keys are used for navigating inside the list.

It also does not work with the tools panel.

"tools panel" are the Tool Settings? What doesn't work there? I just tried a few and all of them worked fine.

Martin

[Martin Huber]

Color Picker inconsistency:

1) use the Color Picker to pick a colour for the fill, stroke, or both.
2) switch to a shape tool.
3) draw a shape

Result: PhotoLine draws the shape in a different colour. The colour last set when the tool was used is retained.
Expected behaviour: PhotoLine ought to respect the colour(s) the user picked with the Color Picker.

IMO the behavior is consistent. The color picker picks colors for the current type of layers.

I understand why you want this, but in practice the behavior you are proposing is a major annoyance, because picking colors while painting in an image will always modify the vector colors. And - to be consistent - picking a color should then modify the text color, too, which would be even more annoying.

Martin

[jw2004]

Chinese Messy Code
I'm from China, when using Text->Serial Document, it shows messy code

Untitled.jpg

[Martin Huber]

Layer effect vector mask bug:

Please open the attached file.

1) move the mask, obscuring more and more of the circle with the layer effect.

Result: the embossing reduces in size.

The emboss size in your example is relative to the layer size. By applying a layer mask, the layer size changes, so the emboss size changes, too.
Switch to an absolute size, and the emboss size will stay the same.

Martin

[Hoogo]

The emboss size in your example is relative to the layer size. By applying a layer mask, the layer size changes, so the emboss size changes, too.
Switch to an absolute size, and the emboss size will stay the same.

I was not sure about that. On top it says "relative to: [page]". Is that just for directions?

[Martin Huber]

The emboss size in your example is relative to the layer size. By applying a layer mask, the layer size changes, so the emboss size changes, too.
Switch to an absolute size, and the emboss size will stay the same.

I was not sure about that. On top it says "relative to: [page]". Is that just for directions?

No, it's for the other parameters, too. A layer has several sizes, and the most relevant are:
- its internal size ("Relative to" is set to "Layer"): If a you transform the layer, the effect is transformed the same way. So even if you are using an absolute size, resizing the layer will change the effect width. If you scale up a layer strongly, you will see that the effect will become pixelated.
- its size relative to the group ("Relative to:" set to "Group"): Similar to "Layer", difference: layer transformation won't transform the effect, but group transformations will.
- its page size ("Relative to" is set to "Page"): transformations don't affect effects.

Martin

[bkh]

ich bin mir nicht ganz sicher, denke aber, dass auch unter macOS der bedingte Trennstrich mit Ctrl+"-" eingegeben werden muss.
Ich kann das Problem hier nicht nachvollziehen. Kannst du mal ein Musterdokument schicken?

Ctrl-"-" fügt bei mir anscheinend U+001F ein (wenn ich Text aus PL in einen Texteditor kopiere und dann die Datei speichere), aber als optionales Trennzeichen funktioniert das bei mir auch nicht. Cmd-"-" fügt anscheinend einen normalen Trennstrich (U+002D) ein.

Ich habe mal eine Datei mit Beispieltexten mit Unicode-Soft-Hyphens und zero width spaces gemacht, die ich hier anhänge.

L.G.

Burkhard.

[Herbert123]

Pixel snapping inconsistency:

1) turn on pixel snapping ("document alignment" --> this should be translated differently. "Pixel Snapping" or "Snap to Pixels" is the correct English term)

I don't understand, what that means. In my English version there is the alignment attribute in the Layer Attributes and there is the command "Layout > Alignment > Align To Pixels".

2) Move any layer.

Result (in most cases): the layer is positioned at a decimal positional value.

Expected: the layer should be positioned to exact pixel values, without decimals, when pixel snapping is activated.

I see no inconsistency: There is an layer attribute and a command. Neither of them is changing or intended to change the behaviour of the Layer Tool.

Martin

Quoted from the documentation:

7.4.58 Alignment/Align To Pixels
The command Align To Pixels aligns the content of the selected layers to the pixel grid of the current document.

For groups the layers within the group will be aligned, too. For vectors the single points of the vector layer might be modified.

This command is similar to the layer attribute Alignment (see chapter 4.11) with the one difference, that this command modifies the layers permanently

(1) "Align to Pixel" is a correct English translation and use. But compare the term "Alignment" in both the Layer panel and the Document panel: that is a confusing word, because what is actually aligned? And the objects are not aligned to pixels - only the visual rendering. In my opinion, the word "Alignment" in these two panels should be renamed to "Snap to Pixel" (that is how it is called in other applications, like Illustrator). Or "Pixel Snapping" - anything but the generic "Alignment"

(2) The word "permanently" in the documentation for the "Align to Pixels" command infers that from that point onward, any scaling and positioning will keep the non-decimal scaling and positional values. It does not: after scaling and positioning, more often than not decimal values are re-introduced.

(3) "Align to Pixels" does not work with text layers. And that is the one really needed, because with small pixel text the pixel rendering changes based on the position. I now have to position pixel text manually by hand again and again and again to maintain the same pixel rendering.

(4) When "Alignment" is activated for either the document or a specific layer, I expect that positioning and scaling with the visual handles and the Layer input fields occur on a non-decimal "pixel" unit basis. But after activating re-positioning and scaling introduce decimal values again.

(5) When "Alignment" for a layer or the document is activated, and even after performing the "Align to Pixels" command, using the arrow keys to position the layer results in decimal values again. (Only works when the user is zoomed to 100%)

Here is how I see it would work best:

a) keep the current function "Align to Pixels", no change to functionality, AND PLEASE also allow it to work on text layers.

b) change the "Alignment" property name in the Layer panel and the Document panel to "Snap to Pixel".

c) when "Snap to Pixel" (Alignment) is active for the document or the active layer, positioning and scaling ALWAYS maintains non-decimal px values. No 60.4px after positioning or scaling: round down to 60px.

d) when "Snap to Pixel" (Alignment) is active for the document or the active layer, using the arrow keys moves the layer by exactly 1 pixel, or 10 pixels with <CTRL> pushed down.

e) if "Snap to Pixels" (Alignment) is turned off, the current behaviour is fine. No changes.

This would be a perfect setup when working with pixel-precise designs. This is also how it tends to work in other applications, for example Illustrator.

[Hoogo]

No, it's for the other parameters, too. A layer has several sizes, and the most relevant are:
- its internal size ("Relative to" is set to "Layer"): If a you transform the layer, the effect is transformed the same way. So even if you are using an absolute size, resizing the layer will change the effect width. If you scale up a layer strongly, you will see that the effect will become pixelated.
- its size relative to the group ("Relative to:" set to "Group"): Similar to "Layer", difference: layer transformation won't transform the effect, but group transformations will.
- its page size ("Relative to" is set to "Page"): transformations don't affect effects.

So "relative to..." affects the scaling of effects when scaling layers or groups, but not the initial size of the effect. Somewhat unexpected, but I'm fine.

[Herbert123]

GUI input fields inconsistency:

It is now possible to use the up and down cursor keys to change the colour values in the colour picker. Great!

However, anywhere else in the GUI this will not work.

You should be able to modify numbers in every text field that contains a numeric value. I just tried a few and didn't find any that didn't work.
But it is not possible to change numeric values with arrow keys in list fields.

For example, I cannot change the position, angle, scaling, etc. with these keys in the layer panel. It also does not work with the tools panel.

As I said, list field don't work because there the arrow keys are used for navigating inside the list.

It also does not work with the tools panel.

"tools panel" are the Tool Settings? What doesn't work there? I just tried a few and all of them worked fine.

Martin

List fields
Using list fields in PhotoLine is somewhat contrary to how input fields and GUIs work in most design software, in my opinion. It is strange that using the arrow keys allows the user to select a row, but how do we enter values with the keyboard only? By pressing <ENTER> the row changes hue, but what then? The standard <tab> key does not switch to the next field in the next row either.

What is also very awkward and time-consuming: to enter a field, the user must click TWICE: once to activate a row, and a second time to enter the field. Next, it is impossible to tab to an input field in the next row. In that case the user must actually click THREE(!) times: click to accept value change, click to select the next row, and finally click again to enter the field.

To change those values with the <ctrl> drag method or middle mouse button also takes an additional click on a row before that action works.

Why force the user to work that hard to just make a single value change?

If you would change these to accepted GUI standards, these list fields ought to work like follows:

1) click an input field once. The input field is activated, and the value is selected blue.
2) use tab and <shift>tab key to enter the next or previous field respectively, irrespective of a "row". Just allow the user to tab to any field.
3) for input fields allow the user to use the up and down arrows (with modifier key for larger increments) to increase the value.
3) for checkboxes and radio buttons: allow the spacebar to turn these on or off.

Tool Settings Fields
a) The text tool settings input fields do not work correctly with the up and down arrow. Only the first keystroke is handled, and after that the focus switches to the text field.
b) it is not possible to use the tab key and keyboard to control the settings found in the tool settings. Sometimes a range of fields can be tabbed, but this does not work when input fields other than text input fields are "in the way".
c) When the text tool is active, and the user tries to change the font size value in the Tools panel at the bottom with the arrow key up and down, only the first keystroke is registered again, and then the focus switches to the actual text object.


Ideally the user would be able to use the tab key to highlight ANY button and any field in any panel, and use the keyboard with either arrow keys (text input fields) or space (non-text fields, other options like checkboxes) to adjust ALL the settings.

[Martin Huber]

Ctrl-"-" fügt bei mir anscheinend U+001F ein (wenn ich Text aus PL in einen Texteditor kopiere und dann die Datei speichere), (...)

Unter macOS werden Trennvorschläge mit Ctrl+Minus eingegeben, und ich habe es gerade hier bei mir ausprobiert, und es funktionierte problemlos.
Es fügt das Zeichen U+0001 ein (das stammt noch aus der Zeit, bevor PhotoLine Unicode unterstützte).

Cmd-"-" fügt anscheinend einen normalen Trennstrich (U+002D) ein.

Cmd+Minus sollte eigentlich gar kein Zeichen einfügen, weil es das Tastenkürzel für Herauszoomen ist. Warum das bei dir was einfügt, ist mir nicht klar.

Ich habe mal eine Datei mit Beispieltexten mit Unicode-Soft-Hyphens und zero width spaces gemacht, die ich hier anhänge.

Ja, ich schaue es mir an, aber das ist ein anderes Problem.

Martin

[Herbert123]

Layer effect vector mask bug:

Please open the attached file.

1) move the mask, obscuring more and more of the circle with the layer effect.

Result: the embossing reduces in size.

The emboss size in your example is relative to the layer size. By applying a layer mask, the layer size changes, so the emboss size changes, too.
Switch to an absolute size, and the emboss size will stay the same.

Martin

Ah, false alarm in this case. I moved the mask to the very extreme, and then the effect must adjust itself to fit that very small space - even when "absolute" size is selected (which I did test). It works as you say. Thanks.

[Herbert123]

Color Picker inconsistency:

1) use the Color Picker to pick a colour for the fill, stroke, or both.
2) switch to a shape tool.
3) draw a shape

Result: PhotoLine draws the shape in a different colour. The colour last set when the tool was used is retained.
Expected behaviour: PhotoLine ought to respect the colour(s) the user picked with the Color Picker.

IMO the behavior is consistent. The color picker picks colors for the current type of layers.

I understand why you want this, but in practice the behavior you are proposing is a major annoyance, because picking colors while painting in an image will always modify the vector colors. And - to be consistent - picking a color should then modify the text color, too, which would be even more annoying.

Martin

Yes, I agree - it would be nice to have some sort of function to quickly copy the color picked colours to the new vector shape colours, though.

[bkh]

Ctrl-"-" fügt bei mir anscheinend U+001F ein (wenn ich Text aus PL in einen Texteditor kopiere und dann die Datei speichere), (...)

Unter macOS werden Trennvorschläge mit Ctrl+Minus eingegeben, und ich habe es gerade hier bei mir ausprobiert, und es funktionierte problemlos.
Es fügt das Zeichen U+0001 ein (das stammt noch aus der Zeit, bevor PhotoLine Unicode unterstützte).

Liegt wohl an der Tastatur. Wenn ich meine Tastatur auf deutsche Tastenbelegung stelle und Ctrl-/ drücke (also da, wo bei der deutschen Tastatur das "-"-Zeichen ist), dann bekomme ich das Trennzeichen. Bei meiner amerikanischen Tastatur funktioniert CTRL-"-" definitiv nicht, auch nicht Ctrl-/. Wenn man weiß, dass man U+0001 braucht, ist die Sache recht einfach: Ctrl-A oder das Einsetzen von U+0001 per "Emoji and Symbols" funktionieren.

CMD-"-" fürs Zoomen habe ich bei mir wohl irgendwann mal ausgeschaltet, ich weiß nicht mehr genau, warum.

L.G.

Burkhard.

[photoken]

Yes, I agree - it would be nice to have some sort of function to quickly copy the color picked colours to the new vector shape colours, though.

Once you have used the Color Picker to pick the colors, the foreground & background swatches in the Toolbox allow you copy the value (RMB to get the context menu), and you can paste the value into the swatches in the tool settings for the vector shape tool. Maybe not as quick as what you're looking for, but it's certainly easy....