Neue Testversion 20.40b6

Hier diskutieren die Betatester von PhotoLine untereinander und mit den Entwicklern
User avatar
Herbert123
Mitglied
Posts: 2009
Joined: Sat 12 May 2012 21:38

Re: Neue Testversion 20.40b6

Post by Herbert123 »

photoken wrote: Tue 21 Mar 2017 03:49
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....
Thanks Ken, I am aware of that option. That's what I usually do, but it gets a bit tedious after having to do this again and again and again (and again) while working on a design last week during which I had to pick many different colours from a bitmap for use in the vector version.

I actually wouldn't mind a checkbox option in the colour picker in order to switch to an alternate mode of colour picking for when many colours must be picked during vector work.
/*---------------------------------------------*/
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
photoken
Mitglied
Posts: 2162
Joined: Sat 28 Sep 2013 01:25

Re: Neue Testversion 20.40b6

Post by photoken »

123,
Yeah, I can appreciate what you're saying. There's probably nothing that doesn't get annoying and tedious if it has to be done so often and so repetitively.... :(

How about if the tool settings panel for the vector shape tools had its own dedicated color-picking eyedropper? Would that help?
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.
User avatar
Hoogo
Betatester
Posts: 3890
Joined: Sun 03 Jul 2005 13:35
Location: Mülheim/Ruhr

Re: Neue Testversion 20.40b6

Post by Hoogo »

----------------
Herr Doktor, ich bin mir ganz sicher, ich habe Atom! /Doctor, doctor, I'm sure, I've got atoms!
bkh
Betatester
Posts: 3661
Joined: Thu 26 Nov 2009 22:59

Re: Neue Testversion 20.40b6

Post by bkh »

Herbert123 wrote: Tue 21 Mar 2017 07:54 I actually wouldn't mind a checkbox option in the colour picker in order to switch to an alternate mode of colour picking for when many colours must be picked during vector work.
Normally, I double-click the colour swatch in the tool setting, then use the colour picker provided by the colour editor – you'll still need to press ok to leave the dialogue. Maybe it's not an obvious solution, though.

Anyway, instead of a checkbox, I'd prefer a colour picker tool/symbol in the vector tool options (that works in the same way as the colour pickers in the adjustment layer panel, i.e., turns itself off after the colour has been selected).

Cheers

Burkhard.
User avatar
Gerhard Huber
Entwickler
Entwickler
Posts: 3990
Joined: Mon 18 Nov 2002 15:30
Location: Bad Gögging

Re: Neue Testversion 20.40b6

Post by Gerhard Huber »

jw2004 wrote: Mon 20 Mar 2017 15:46 Chinese Messy Code
I'm from China, when using Text->Serial Document, it shows messy code
can you send me the CSV file to see where the problem is?
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 20:17(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"
We will change that to "Pixel Snapping".
Herbert123 wrote: Mon 20 Mar 2017 20:17(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.
No, "permanently" infers that you can't turn that pixel snapping off later - in contrast to the temporary attribute in the Layer Attributes.
Herbert123 wrote: Mon 20 Mar 2017 20:17(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.
Pixel snapping is just plain ugly in combination with small text.
I could force text output to use the OS if pixel snapping is enabled. On Windows this will create sharper text, because Windows uses font hinting. On macOS it won't help at all, because macOS doesn't use font hinting. Und font kerning will be worse with OS output.
Herbert123 wrote: Mon 20 Mar 2017 20:17(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%)
It might be your expectation that this attribute will produce non-fractional positions, but that's not the intended behavior of an attribute.
In fact, enforcing non-fractional positions and sizes might produce deformed vector layers, if the vector layer is edited afterwards.

Martin
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 20:23So "relative to..." affects the scaling of effects when scaling layers or groups, but not the initial size of the effect.
If a layer is scaled, it affects the initial size of the effect, too.

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: Thu 23 Mar 2017 12:16
Herbert123 wrote: Mon 20 Mar 2017 20:17(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"
We will change that to "Pixel Snapping".
Herbert123 wrote: Mon 20 Mar 2017 20:17(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.
No, "permanently" infers that you can't turn that pixel snapping off later - in contrast to the temporary attribute in the Layer Attributes.
Herbert123 wrote: Mon 20 Mar 2017 20:17(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.
Pixel snapping is just plain ugly in combination with small text.
I could force text output to use the OS if pixel snapping is enabled. On Windows this will create sharper text, because Windows uses font hinting. On macOS it won't help at all, because macOS doesn't use font hinting. Und font kerning will be worse with OS output.
Herbert123 wrote: Mon 20 Mar 2017 20:17(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%)
It might be your expectation that this attribute will produce non-fractional positions, but that's not the intended behavior of an attribute.
In fact, enforcing non-fractional positions and sizes might produce deformed vector layers, if the vector layer is edited afterwards.

Martin
Thank you for word change.

My main concern is that currently, after aligning an object to pixels, and turning on pixel snapping for that layer, and pixel mode is active re-positioning that object with the layer tool will still allow it to be positioned at decimal pixel values.

The same behaviour occurs when the document is set to pixel snapping, and the view to pixel mode: after drawing a rectangle or placing and positioning an image (and the view is for example 125%) more often than not the positions are not set to full pixels, but something like 20.4px / 64.7px.

As for text: the point is again that each text instance is rendered the same by aligning it to pixels. Now I am forced to reset the position values to round values for each text instance to ensure the pixels look identical. And once positioned like that, moving it again places more often than not at fractional pixel values, and I have to reset those values again.

Anyway, I am just requesting that when pixel mode and pixel snapping are both active, no matter what the element is (shape, text, bitmap), a layer should not be allowed to be positioned at fractional pixel values at all after positioning it. (And this is how it works in other applications.) Always snap to full pixels in this case! And when new shapes are drawn positioning and scaling should snap to full pixels as well and result in rounded pixels if possible.
Last edited by Herbert123 on Thu 23 Mar 2017 17:22, edited 3 times in total.
/*---------------------------------------------*/
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 »

SVG import bug:

When a SVG has a width and height of 100% set, PhotoLine imports and scales the file to 100px by 100px. It should probably just ignore those values when percentages are used.

I attached a sample file.
You do not have the required permissions to view the files attached to this post.
/*---------------------------------------------*/
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: Tue 21 Mar 2017 02:26Liegt 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.
Das ist sehr seltsam, denn laut der "Tastaturübersicht" sollte Ctrl den Tastenwert nicht verändern (d.h. bei Ctrl+A sollte ich ein "a" bekommen, und bei Ctrl+Shift+A ein "A"), und bei der deutschen Tastaturbelegung ist das auch so.

Wie auch immer: Ich schaue mir das an.

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: Tue 21 Mar 2017 07:54I actually wouldn't mind a checkbox option in the colour picker in order to switch to an alternate mode of colour picking for when many colours must be picked during vector work.
I changed the Color Picker, so that pressing and holding its shortcut key, it will be accessed temporarily (just like the Rotate View tool with "r").
But the Color Picker doesn't have a default shortcut. Maybe it should get one?

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: Thu 23 Mar 2017 17:42
Herbert123 wrote: Tue 21 Mar 2017 07:54I actually wouldn't mind a checkbox option in the colour picker in order to switch to an alternate mode of colour picking for when many colours must be picked during vector work.
I changed the Color Picker, so that pressing and holding its shortcut key, it will be accessed temporarily (just like the Rotate View tool with "r").
But the Color Picker doesn't have a default shortcut. Maybe it should get one?

Martin
<i> seems to be the key used in other applications. Yes, sounds like a good idea to me.
/*---------------------------------------------*/
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: Thu 23 Mar 2017 17:38
bkh wrote: Tue 21 Mar 2017 02:26Liegt 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.
Das ist sehr seltsam, denn laut der "Tastaturübersicht" sollte Ctrl den Tastenwert nicht verändern (d.h. bei Ctrl+A sollte ich ein "a" bekommen, und bei Ctrl+Shift+A ein "A"), und bei der deutschen Tastaturbelegung ist das auch so.

Wie auch immer: Ich schaue mir das an.

Martin
Yes, same problem here. Caps Lock blocks the use of other keys like <x> and <d>. Any other key, it seems.
/*---------------------------------------------*/
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: 3890
Joined: Sun 03 Jul 2005 13:35
Location: Mülheim/Ruhr

Re: Neue Testversion 20.40b6

Post by Hoogo »

Wo ich das grade sehe: Ist es Absicht, dass die Farb-Eigenschaft von monochrom-Ebenen nur im Dokumentenmodus verfügbar ist?
----------------
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: Thu 23 Mar 2017 22:22 Wo ich das grade sehe: Ist es Absicht, dass die Farb-Eigenschaft von monochrom-Ebenen nur im Dokumentenmodus verfügbar ist?
Wenn ich nicht was übersehen habe, ist das nicht so. Aber die Farbeigenschaften von monochromen Ebenen sollte nur in "farbigen" Dokumenten verfügbar - unabhängig vom Dokumentmodus.

Martin