Neue Testversion 20.40b6

Hier diskutieren die Betatester von PhotoLine untereinander und mit den Entwicklern
Martin Huber
Entwickler
Entwickler
Posts: 3942
Joined: Tue 19 Nov 2002 15:49

Re: Neue Testversion 20.40b6

Post by Martin Huber »

Herbert123 wrote: Fri 17 Mar 2017 00:40 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.
Herbert123 wrote: Fri 17 Mar 2017 00:40For 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.
Herbert123 wrote: Fri 17 Mar 2017 00:40It 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
Entwickler
Entwickler
Posts: 3942
Joined: Tue 19 Nov 2002 15:49

Re: Neue Testversion 20.40b6

Post by Martin Huber »

Herbert123 wrote: Fri 17 Mar 2017 00:36 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
Mitglied
Posts: 86
Joined: Sun 15 Mar 2015 05:59

Re: Neue Testversion 20.40b6

Post by jw2004 »

Chinese Messy Code
I'm from China, when using Text->Serial Document, it shows messy code
Untitled.jpg
You do not have the required permissions to view the files attached to this post.
PL19 x64 win7 64
Martin Huber
Entwickler
Entwickler
Posts: 3942
Joined: Tue 19 Nov 2002 15:49

Re: Neue Testversion 20.40b6

Post by Martin Huber »

Herbert123 wrote: Mon 20 Mar 2017 00:25 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
User avatar
Hoogo
Betatester
Posts: 3888
Joined: Sun 03 Jul 2005 13:35
Location: Mülheim/Ruhr

Re: Neue Testversion 20.40b6

Post by Hoogo »

Martin Huber wrote: Mon 20 Mar 2017 15:55The 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?
----------------
Herr Doktor, ich bin mir ganz sicher, ich habe Atom! /Doctor, doctor, I'm sure, I've got atoms!
Martin Huber
Entwickler
Entwickler
Posts: 3942
Joined: Tue 19 Nov 2002 15:49

Re: Neue Testversion 20.40b6

Post by Martin Huber »

Hoogo wrote: Mon 20 Mar 2017 16:02
Martin Huber wrote: Mon 20 Mar 2017 15:55The 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
Betatester
Posts: 3661
Joined: Thu 26 Nov 2009 22:59

Re: Neue Testversion 20.40b6

Post by bkh »

Gerhard Huber wrote: Mon 20 Mar 2017 12:44 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.
You do not have the required permissions to view the files attached to this post.
User avatar
Herbert123
Mitglied
Posts: 2009
Joined: Sat 12 May 2012 21:38

Re: Neue Testversion 20.40b6

Post by Herbert123 »

Martin Huber wrote: Mon 20 Mar 2017 10:52
Herbert123 wrote: Fri 17 Mar 2017 00:45 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".
Herbert123 wrote: Fri 17 Mar 2017 00:452) 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.
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
User avatar
Hoogo
Betatester
Posts: 3888
Joined: Sun 03 Jul 2005 13:35
Location: Mülheim/Ruhr

Re: Neue Testversion 20.40b6

Post by Hoogo »

Martin Huber wrote: Mon 20 Mar 2017 16:17No, 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.
----------------
Herr Doktor, ich bin mir ganz sicher, ich habe Atom! /Doctor, doctor, I'm sure, I've got atoms!
User avatar
Herbert123
Mitglied
Posts: 2009
Joined: Sat 12 May 2012 21:38

Re: Neue Testversion 20.40b6

Post by Herbert123 »

Martin Huber wrote: Mon 20 Mar 2017 13:22
Herbert123 wrote: Fri 17 Mar 2017 00:40 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.
Herbert123 wrote: Fri 17 Mar 2017 00:40For 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.
Herbert123 wrote: Fri 17 Mar 2017 00:40It 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.
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
Martin Huber
Entwickler
Entwickler
Posts: 3942
Joined: Tue 19 Nov 2002 15:49

Re: Neue Testversion 20.40b6

Post by Martin Huber »

bkh wrote: Mon 20 Mar 2017 19:56 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).
bkh wrote: Mon 20 Mar 2017 19:56 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.
bkh wrote: Mon 20 Mar 2017 19:56 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
User avatar
Herbert123
Mitglied
Posts: 2009
Joined: Sat 12 May 2012 21:38

Re: Neue Testversion 20.40b6

Post by Herbert123 »

Martin Huber wrote: Mon 20 Mar 2017 15:55
Herbert123 wrote: Mon 20 Mar 2017 00:25 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.
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
User avatar
Herbert123
Mitglied
Posts: 2009
Joined: Sat 12 May 2012 21:38

Re: Neue Testversion 20.40b6

Post by Herbert123 »

Martin Huber wrote: Mon 20 Mar 2017 15:45
Herbert123 wrote: Fri 17 Mar 2017 00:36 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.
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
bkh
Betatester
Posts: 3661
Joined: Thu 26 Nov 2009 22:59

Re: Neue Testversion 20.40b6

Post by bkh »

Martin Huber wrote: Mon 20 Mar 2017 21:13
bkh wrote: Mon 20 Mar 2017 19:56 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.
User avatar
photoken
Mitglied
Posts: 2162
Joined: Sat 28 Sep 2013 01:25

Re: Neue Testversion 20.40b6

Post by photoken »

Herbert123 wrote: Mon 20 Mar 2017 21:25 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....
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.