Neue Testversion 18.40b12

[Christopher]

PhotoLine unterstützt unter Windows Hunspell und Aspell.
Leider unterstützt die "Opensourcegemeinde" Windows nicht wirklich, daher ist es schwierig, bis nicht möglich sich 64-Bit Binaries zu laden.
Ich habe mir die Dinger selbst compiliert, bin mir aber nicht im Klaren, wie die Verteilung rechtlich ist, daher mache ich die Teile nicht frei zugänglich.
Gerhard

Hallo Gerhard,

kannst du uns eine Schritt für Schritt Anleitung für Dummies zur Verfügung stellen, wie das Zeug zu compilieren ist, dann könnte dies ja evtl. jeder für sich erledigen?

Danke

[Gerhard Huber]

kannst du uns eine Schritt für Schritt Anleitung für Dummies zur Verfügung stellen, wie das Zeug zu compilieren ist, dann könnte dies ja evtl. jeder für sich erledigen?

ich habe das mit der Profiversion von Visual Studio gemacht, da werden wenige Leute Zugriff haben. Außerdem ist das schon einige Zeit her und ich habe nicht mitgeschrieben

Gerhard

[Martin Huber]

Mit einem neuen Dokument als Hintergrund und Bildebenen kann man diese in verschiedenen Farben darstellen. Ich denke aber die jetzige Implementierung ist nicht so vielseitig gewählt, da die Funktion nur für Grauebenen zu funktionieren scheint.

Die jetzige Implementierung ist so ausgelegt, dass man das Ergebnis auch drucken kann. Wenn man das flexibler macht, ist das nur noch bedingt möglich.

Wäre es nicht sinnvoll, dies für alle Ebenen zu erlauben, bei Bedarf eben basierend auf deren Interpretation in Grautönen ähnlich der Verwendung einer Maske? (Dafür müsste die Farbe nur angewandt werden wenn die Farbauswahl wenn nicht den Vorgabe wert (transparent) zeigt.)
Sinn würde es z.b. machen, virtuellen Kopien jeweils andere Farben zu geben, oder Gruppen von Vektoren gemeinsam eine Farbe zuzuweisen oder natürlich auch Bildcontainer monochrom anzuzeigen.

Bei Bildern geht das doch recht flexibel, wenn man ihnen eine Falschfarben-Arbeitsebene als Kind zuweist.
Und bei Vektorebenen wäre es besser, wirklich die Farbe zu ändern.

Beim Benutzen des Bilddialogs wird das Auswahlfeld schnell neu gezeichnet, man sieht aber nicht gleich die Änderung im Dokument - evtl. ist hier noch mehr WYSIWYG möglich

Das werde ich ändern.

Martin

[NoSi]

... Allerdings finde ich weder den "Berabeiten-Knopf", noch kann ich mehrere Stile anlegen oder durch Ziehen die Reihenfolge ändern. Finde ich schade, denn das ist/war eine mächtige Funktion, mit der viele Arbeiten (für mich) deutlich schneller und einfacher von der Hand gingen (z.B. Karten-Malen).

die Funktionalität steckt seit einiger Zeit im Attributedialog unter "Ebene". Wähle die Zeile mit der Füll-/Linienfarbe an und du kannst unten die Zeile verdoppeln.

Gerhard

HRGH. Selbst ver.... . Ich habe mich derart auf das Kontextmenü konzentriert, dass ich die beiden Knöpfe unten schlicht übersehen habe. Mächtigkeit macht es bzgl. Bedienung nicht einfacher. Aber richtig Kucken muss schon... ) Danke.

[NoSi]

Ist eine Lösung absehbar, wie die Rechtschreibkontrolle in der x64-Version wieder aktiviert werden kann? Unter x32 läuft das bei mir, die x64 Version (die ich bevorzugt nutze) habe ich keine. An der Installation des Aspell kann es (weil x32 klappt) nicht liegen.

PhotoLine unterstützt unter Windows Hunspell und Aspell.
Leider unterstützt die "Opensourcegemeinde" Windows nicht wirklich, daher ist es schwierig, bis nicht möglich sich 64-Bit Binaries zu laden.
Ich habe mir die Dinger selbst compiliert, bin mir aber nicht im Klaren, wie die Verteilung rechtlich ist, daher mache ich die Teile nicht frei zugänglich.

Gerhard

Wie wäre eine knappe Anfrage beim Maintainer des Windows-Ports von Aspell?
GNU Aspell (Win32 version) this port is maintained by Thorsten Maerz (info@netztorte.de)

Ich denke, wenn man ein fertig kompiliertes Paket anbietet, wird der nicht lang fragen. Grundsätzlich sehe ich aber bei den GNU-Konditionen eine Weitergabe kein Problem. Ist Open Source. (s. http://www.gnu.org , Was ist freie Software). Imo stünde einer Weitergabe im Rahmen des Installs - wenn ein entsprechender Hinweis auf die Quellen dabei liegt, nichts im Weg.

[NoSi]

Unter Windows 8.1 pro x64 habe ich den Effekt, dass der "Bilder" Ordner in der Bildübersicht als "Pictures" gelistet wird. Mit "Öffnen" ist die Darstellung und Einsortierung korrekt.

[Gerhard Huber]

Unter Windows 8.1 pro x64 habe ich den Effekt, dass der "Bilder" Ordner in der Bildübersicht als "Pictures" gelistet wird. Mit "Öffnen" ist die Darstellung und Einsortierung korrekt.

Das ist auch in den anderen Windowsversionen so. Die Lokalisierung nimmt Windows an der Oberfläche vor.

Gerhard

[photoken]

Using Win7 x64 SP1
PL 18.40b12 x64 (also happens with PL 18.02 x64)

When I launch PL, I first see the splash screen, then the PL application window appears, and then a second or so later a small window flashes onscreen for a fraction of a second. What is that small window? If I try to select, for example, File...Open as soon as the main window appears, that small window cancels the operation and I have to re-select the menu item.

[Herbert123]

Lately I have been getting more print jobs again, and I have a coupe of suggestions:

1) when I place or import an image in an A4 document, the ppi settings of the images are not respected at all. I would expect two images with the same pixel resolution, but with different ppi settings (let's say 300ppi and 72ppi) to be placed with very different dimensions on the page.

A bitmap at 1106x1600px @ 300ppi should be placed in a 300ppi A4 at 93.641mm x 135.467mm. The same file at 72ppi would be placed at 390.172mm x 564.444mm.

This is how it works in other dtp apps:

Untitled2.jpg

This does not happen. Both files are placed with an arbitrary size depending on the size of the drawn rectangle, and that makes it extremely difficult to work with print images. Any other dtp related application will calculate the placed bitmap's dimensions on the basis of the documents base ppi/dimensions, and the placed image's ppi.

Solution: a simple checkbox in the settings for this tool to tell it to keep this relationship intact or use the box's dimensions as a base for its placed size.

2) a ppi field (like the one for the document properties) should be added, so the user can see what the placed image's ppi is in relation to the document. For example, if option (1) is implemented, the EFFECTIVE (calculated) ppi of this layer should be displayed, as well as the file's embedded ppi. A bit like this:

Untitled.jpg

These could be added to the layer properties of a bitmap layers and placeholder layers.

3) It would be extremely useful to be able to change the effective (calculated) ppi of a layer, and Photoline will then automatically recalculate the size of the layer.

4) in "new document" the correct English word for "distance" between columns is "Gutter".

5) Photoline uses "dpi" everywhere when it really means "ppi". It's a common mistake - when talking about resolution of images while working on a screen, "ppi" is the correct term. When talking about a print on paper or the output quality for a particular print device, "dpi" is used.

6) master pages support would be great for the pages panel... Not only for print, but also for screen and web design.

7) an automatic guide calculator option would be awesome - both for pages, as well as for selections. Perfect implementation: http://guideguide.me/

it would be extremely useful if we could have guides added to specific layers, and show or hide them that way. Far more guide control that way. Also a way to select multiple guides and move those with the mouse.

[Herbert123]

Btw, is there an easy way to create a new monochrome layer at 1200ppi at document size? The new layer dialog lacks a ppi value.

I ask this, because I am working on an illustration where I have two layers for print: a cmyk layer for the colours, and a 1200ppi layer for the b&w line art.

There does not seem to be an easy method to generate a 1200ppi monochrome layer for a 300ppi cmyk A4 document. The only method I know of is to create a new layer by multiplying the px values by 4, and then scaling down the layer to 1200ppi.

[evren]

when I place or import an image in an A4 document, the ppi settings of the images are not respected at all. I would expect two images with the same pixel resolution, but with different ppi settings (let's say 300ppi and 72ppi) to be placed with very different dimensions on the page.

Photoline uses resolution values as a part of losless image editing. I also realized after. Changing PPI instead of real size. And keeping rotate, skew, distort, filter etc. values numerically. That's why PPI never mets as you expect. But me also doing too much complicated print job and never had problem. I scale as I want but in print gives exact. But if you try to print layer basis (not all page) maybe it can. I didn't try it. If you want to "Fix" resolution to main picture/document size, simply click "Fix" command as self explains. But it will also clear or non-destructive data. And I guess you already know this. Just to remind.

And also keep in mind that, Photoline have an awkward behaviour to tread vectors (same non-destructive model) but buggy. Once you resize a vector (shape line whatever), if you try to resize again from resize panel to a size, it never resizes to that size. It considers vectors resized (changed) resolution instead of document default. Solution simple. If working with vectors too much like me, click on fix before all exact-resize operations. By the way maybe it changed. I'll try now.

Photoline uses "dpi" everywhere when it really means "ppi". It's a common mistake - when talking about resolution of images while working on a screen, "ppi" is the correct term. When talking about a print on paper or the output quality for a particular print device, "dpi" is used.

Me also mentioned this once that Photoline doesn't need to follow the mistakes of other softwares for sake of being easy to read. All designers will understand. Even they will not know the difference. Also mentioned about un-scalable vectors but. Maybe one day.

an automatic guide calculator option would be awesome - both for pages, as well as for selections. Perfect implementation: http://guideguide.me/

Ah yes... When it comes to print jobs, guides become pain. What I need most of the time is to put margin from both sides 0,7 cm inside etc. etc. And sometimes divided documents for calatogs etc.
What I do for overcoming is, for example when a layout divided in 5 needed, I put vector lines and arrange them automatically from alignement tools. After fix guides to them and delete vectors. Or using vector boxes (like 0,7cm) to define document edges. Ruler? Sure I know :) But had to change it's origin many times to do these.

All bests

[bkh]

1) when I place or import an image in an A4 document, the ppi settings of the images are not respected at all. I would expect two images with the same pixel resolution, but with different ppi settings (let's say 300ppi and 72ppi) to be placed with very different dimensions on the page.

Generally, PL respects ppi settings in document mode. However, this changes when the image doesn't fit the document borders – in that case, the image is scaled to fit. I've also had cases where this was undesirable (and worked around it by using a large enough document and by setting the correct document size only after the import, but I wouldn't mind if Document Mode always respected the images' ppi values. (Presumably, the reason behind PL's current behaviour is that many images these days, especially from cameras, have arbitrary ppi settings.)

2) a ppi field (like the one for the document properties) should be added, so the user can see what the placed image's ppi is in relation to the document. For example, if option (1) is implemented, the EFFECTIVE (calculated) ppi of this layer should be displayed, as well as the file's embedded ppi.

Currently, PL shows the calculated ppi in the Attributes panel. You are right, the native resolution might be useful as well.

3) It would be extremely useful to be able to change the effective (calculated) ppi of a layer, and Photoline will then automatically recalculate the size of the layer.

Works here, just change the value in the Attributes panel.

Cheers

Burkhard.

[bkh]

There does not seem to be an easy method to generate a 1200ppi monochrome layer for a 300ppi cmyk A4 document. The only method I know of is to create a new layer by multiplying the px values by 4, and then scaling down the layer to 1200ppi.

You could create a new layer at document size, and then use the "Resolution" scaling mode to scale it up to 1200 dpi.

Cheers

Burkhard.

[Martin Huber]

5) Photoline uses "dpi" everywhere when it really means "ppi". It's a common mistake - when talking about resolution of images while working on a screen, "ppi" is the correct term. When talking about a print on paper or the output quality for a particular print device, "dpi" is used.

I see no reason for differentiating between "dpi" and "ppi":
- Most people use "dpi".
- A pixel is a dot, too.
- There is no intersection between the fields of application of "dpI" and "ppi", so there is no risk of a misunderstanding.
- The producers of flatbed scanners state the resolution in dpi, too, and they don't scan "dots" but "pixels" (which is in my opinion the same).

Martin

[Martin Huber]

Generally, PL respects ppi settings in document mode. However, this changes when the image doesn't fit the document borders – in that case, the image is scaled to fit. I've also had cases where this was undesirable (and worked around it by using a large enough document and by setting the correct document size only after the import, but I wouldn't mind if Document Mode always respected the images' ppi values. (Presumably, the reason behind PL's current behaviour is that many images these days, especially from cameras, have arbitrary ppi settings.)

In the past we always respected the dpi value, but we changed that because of user complaints. As you said yourself many files have arbitrary dpis, but there are also a lot of files with nonsense dpis, for example megapixel images with dpi values of 1.

Currently, PL shows the calculated ppi in the Attributes panel. You are right, the native resolution might be useful as well.

Is there a common situation, where it is useful to show the native dpi? You have to keep in mind, that each additional line in the Layer Attributes makes them less useful. I am still asking myself whether the overprint settings are so important to show them in the Layer Attributes.

Martin