Neue Testversion 16.40b10
-
- Betatester
- Posts: 3675
- Joined: Thu 26 Nov 2009 22:59
Re: Neue Testversion 16.40b10
Wenn man in den Voreinstellungen als Hintergrundfarbe für Bilder eine transparente Farbe eingestellt hat (um beim Beschnitt gedrehte Bilder ganz zu sehen) und ein Bild mit Transparenz erzeugt, wird auch der Hintergrund außerhalb des Bildes transparent angezeigt. Bei mir ist die Hintergrundfarbe 50 % Grau, 50 % Transparenz.
L.G.
Burkhard.
Wenn man die Transparenz ein/ausschaltet, sieht man den Effekt manchmal nicht gleich (oder nur in einem schmalen Rahmen um das Bild), sondern erst, wenn das Fenster (z. B. beim Vergrößern/Verkleinern) neu gezeichnet wird.L.G.
Burkhard.
You do not have the required permissions to view the files attached to this post.
-
- Betatester
- Posts: 3675
- Joined: Thu 26 Nov 2009 22:59
Re: Neue Testversion 16.40b10
Das Äquivalent zur Eieruhr sehe ich beim Mac auch, das liegt daran, dass PL beim Rechnen nicht auf das Betriebssystem reagiert, und daher kommt möglicherweise auch das Hüpfen im Taskbar? Kenne mich mit Win 7 nicht aus. Ein Bildaufbau dauert bei mir ein paar Sekunden. Aber das erstaunt mich eigentlich auch nicht weiter - deine Vektorgrafiken haben ja auch so einige Punkte, und dass das mit den zusätzlichen Effekten trotzdem klappt, ist für mich eher ein mittleres Wunder … großes Kompliment an die Hubers!Hoogo wrote:Ich habe da genommen, was halt grad auf dem Desktop lag.
Könnte ein Problem mit Win7 sein. Wenn ich PL in der 32Bit-Fassung starte, ist auch schon ein Wert von 200 drollig. Das Dialogfensterchen hüpft regelmäßig ein bisschen zur Seite und wieder zurück, die Eieruhr erscheint und verschwindet wieder... Und das PL-Icon in der Taskbar hüpft auch kurz herum.
Das mit dem "hüpfenden" DIalog ist natürlcih blöd, sowas sehe ich nicht.
Ich habe auch mal probiert, die Anfangs- und Endvektorgrafiken mittels "Ebene fixieren" in normale Vektorgrafiken ohne Extra-Effekte zu wandeln. Das Ergebnis sieht aber ziemlich anders aus, und deutlich schneller wird's dadurch auch nicht.
L.G.
Burkhard.
-
- Entwickler
- Posts: 4208
- Joined: Tue 19 Nov 2002 15:49
Re: Neue Testversion 16.40b10
Ja, das ist Absicht. Wieso siehst du das als Fehler an?bkh wrote:Wenn man in den Voreinstellungen als Hintergrundfarbe für Bilder eine transparente Farbe eingestellt hat (um beim Beschnitt gedrehte Bilder ganz zu sehen) und ein Bild mit Transparenz erzeugt, wird auch der Hintergrund außerhalb des Bildes transparent angezeigt. Bei mir ist die Hintergrundfarbe 50 % Grau, 50 % Transparenz.
Martin
-
- Betatester
- Posts: 3675
- Joined: Thu 26 Nov 2009 22:59
Re: Neue Testversion 16.40b10
Ok, das ist auch schon bei der 16.11 auch so. Hatte ich bisher nicht bemerkt, weil mein Bildhintergrund immer opak war. Wegen des Beschneiden-Tools habe ich ihn wohl erst jetzt auf halbtransparent gesetzt.Martin Huber wrote:Ja, das ist Absicht. Wieso siehst du das als Fehler an?bkh wrote:Wenn man in den Voreinstellungen als Hintergrundfarbe für Bilder eine transparente Farbe eingestellt hat (um beim Beschnitt gedrehte Bilder ganz zu sehen) und ein Bild mit Transparenz erzeugt, wird auch der Hintergrund außerhalb des Bildes transparent angezeigt. Bei mir ist die Hintergrundfarbe 50 % Grau, 50 % Transparenz.
Aber: Zum einen ist das Umschaltverhalten merkwürdig: wenn man bei den Attributen die Transparenz ein- und ausschaltet, wird nicht der gesamte Hintergrund geändert, sondern nur ein schmaler Rahmen um das Bild herum. (Wenn ich das über Ebeneneigenschaften mache, ist das Umschaltverhalten richtig.)
Zum anderen finde ich das Verhalten unlogisch: wieso beeinflusst das Bild den Hintergrund, vor dem es dargestellt wird? Wenn die Hintergrundfarbe (halb)transparent ist, sollte der Hintergrund entweder immer oder nie halbtransparent sein, unabhängig davon, ob das Bild selbst Transparenz hat oder nicht.
Mich persönlich macht das Karomuster im Hintergrund wahnsinnig. Ich stelle gerne wieder eine opake Farbe ein, wenn beim Drehen/Entzerren mit dem Beschneiden-Tool mein Bild nicht mehr hinter(!) dem Hintergrund verschwindet, und ebenso alle anderen Dinge, die aus dem Bild "herausragen".
Ich überlege gerade, ob es nicht unter "Ansicht" einfach die Möglichkeit geben sollte, die Anzeige beim Bildrand abzuschneiden oder alles anzuzeigen (vielleicht schattiert), was über den Bildrand hinausragt. Beide Varianten können ja sinnvoll sein.
L.G.
Burkhard.
-
- Entwickler
- Posts: 4208
- Joined: Tue 19 Nov 2002 15:49
Re: Neue Testversion 16.40b10
Das ist ein Fehler und ich werde das ändern.bkh wrote:Aber: Zum einen ist das Umschaltverhalten merkwürdig: wenn man bei den Attributen die Transparenz ein- und ausschaltet, wird nicht der gesamte Hintergrund geändert, sondern nur ein schmaler Rahmen um das Bild herum. (Wenn ich das über Ebeneneigenschaften mache, ist das Umschaltverhalten richtig.)
Hat ein Dokument Transparenz ist diese Transparenz auch außerhalb der Dokumentgrenzen. Alles andere wäre inkonistent, da sonst eine Ebene abhängig von ihrer Lage anders dargestellt werden müsste. Und das Schachbrettmuster repräsentiert die Transparenz.bkh wrote:Zum anderen finde ich das Verhalten unlogisch: wieso beeinflusst das Bild den Hintergrund, vor dem es dargestellt wird? Wenn die Hintergrundfarbe (halb)transparent ist, sollte der Hintergrund entweder immer oder nie halbtransparent sein, unabhängig davon, ob das Bild selbst Transparenz hat oder nicht.
Du kannst die Farbe der "bunten" Quadrate unter "Einstellungen/Anzeige/Transparenz" ändern, und sie theoretisch auch auf weiß stellen.bkh wrote:Mich persönlich macht das Karomuster im Hintergrund wahnsinnig.
Ja, das ist nicht schön. Ich werde das Zeichnen des Randes so umbauen, dass er sich im Bildmodus wie im Dokumentmodus verhält.bkh wrote:Ich stelle gerne wieder eine opake Farbe ein, wenn beim Drehen/Entzerren mit dem Beschneiden-Tool mein Bild nicht mehr hinter(!) dem Hintergrund verschwindet, und ebenso alle anderen Dinge, die aus dem Bild "herausragen".
Martin
-
- Betatester
- Posts: 1041
- Joined: Mon 07 Jan 2008 19:52
- Location: Birkenwerder / Berlin
Re: Neue Testversion 16.40b10
Nö, ist nicht aktuell. Sonst stünde das mit den Shortcuts für´s Drehen mit drin, oder?Gerhard Huber wrote:doch, die Hilfe ist aktuell - für die Version 16.50, d.h. die Funktionen, die nicht in der 16.50 sein werden, haben auch keine Hilfe bekommengmhofmann wrote:die integrierte Hilfe ist aber noch nicht aktualisiert, oder?
Gerhard
Grüße
Norbert
Screencasts zu Photoline: http://www.buoa.de • Win 10x64 / PL64, immer die aktuellste Beta-Version.
-
- Entwickler
- Posts: 4208
- Joined: Tue 19 Nov 2002 15:49
Re: Neue Testversion 16.40b10
Welche Tastenkürzel fehlen? Alt+Pfeil links und Alt+Pfeil rechts? Ich kann jetzt nur für die Mac-Version sprechen, aber da werden die beiden Tasten sowohl im Ebenenwerkzeug als auch im Beschneiden-Werkzeug erwähnt.NoSi wrote:Nö, ist nicht aktuell. Sonst stünde das mit den Shortcuts für´s Drehen mit drin, oder?Gerhard Huber wrote:doch, die Hilfe ist aktuell - für die Version 16.50, d.h. die Funktionen, die nicht in der 16.50 sein werden, haben auch keine Hilfe bekommen
Martin
-
- Betatester
- Posts: 3675
- Joined: Thu 26 Nov 2009 22:59
Re: Neue Testversion 16.40b10
Ich habe gerade bei der Gelegenheit gesehen, dass ihr die Apple-Gesten fürs Drehen unterstützt. Wollt ihr ggf. auch die vom Wacom Touch unterstützen? Das Tablett sendet (beim Mac) beim Drehen einfach die Tastenkürzel CMD-L bzw. CMD-R. Zoom und Scrollen gehen mit dem Wacom ja schon.Martin Huber wrote:NoSi wrote:Gerhard Huber wrote:doch, die Hilfe ist aktuell - für die Version 16.50, d.h. die Funktionen, die nicht in der 16.50 sein werden, haben auch keine Hilfe bekommen
L.G.
Burkhard.
-
- Betatester
- Posts: 318
- Joined: Fri 28 May 2004 18:05
- Location: Wien
Re: Neue Testversion 16.40b10
Das ist ja toll! Mit gedrückter Umschalttaste in 45°-Schritten. Wollt ihr das nicht auch mit einer Bemerkung in der Hilfe erwähnen?bkh wrote:Ich habe gerade bei der Gelegenheit gesehen, dass ihr die Apple-Gesten fürs Drehen unterstützt. […]
Michael
Macbook Pro, macOS X (X = neueste Version)
https://instagram.com/m_frankenstein/
https://frankenste.info/m/
Macbook Pro, macOS X (X = neueste Version)
https://instagram.com/m_frankenstein/
https://frankenste.info/m/
-
- Entwickler
- Posts: 4208
- Joined: Tue 19 Nov 2002 15:49
Re: Neue Testversion 16.40b10
PhotoLine unterstützt mittlerweile alle Standardgesten.bkh wrote:Ich habe gerade bei der Gelegenheit gesehen, dass ihr die Apple-Gesten fürs Drehen unterstützt.
Die "Manie" von Wacom, anstelle der Gesten Tastenklicks zu verschicken, ist Pfusch. Wacom wird im Touch-Bereich nur dann eine Zukunft habe, wenn sie kompatibel zu den Gesten des jeweiligen Betriebssystems werden. Aber das wollen oder können sie nicht.bkh wrote:Wollt ihr ggf. auch die vom Wacom Touch unterstützen? Das Tablett sendet (beim Mac) beim Drehen einfach die Tastenkürzel CMD-L bzw. CMD-R. Zoom und Scrollen gehen mit dem Wacom ja schon.
Martin
-
- Entwickler
- Posts: 4208
- Joined: Tue 19 Nov 2002 15:49
Re: Neue Testversion 16.40b10
Grundsätzlich ist die Umschalttaste immer - wo es sinnvoll ist - die "Einschränkungstaste". Beim Skalieren wird nur noch proportional skaliert, beim Verschieben nur noch in Grundwinkeln verschoben, usw.frankenstein wrote:Das ist ja toll! Mit gedrückter Umschalttaste in 45°-Schritten. Wollt ihr das nicht auch mit einer Bemerkung in der Hilfe erwähnen?bkh wrote:Ich habe gerade bei der Gelegenheit gesehen, dass ihr die Apple-Gesten fürs Drehen unterstützt. […]
Ich gebe dir recht, dass es optimal wäre, das bei jedem einzelnen Werkzeug zu dokumentieren. Aber gerade die Dokumentation des Ebenenwerkzeugs ist mittlerweile recht lang, so dass ich befürchte, dass die heute schon kaum einer mehr ganz durchliest.
Martin
-
- Betatester
- Posts: 1041
- Joined: Mon 07 Jan 2008 19:52
- Location: Birkenwerder / Berlin
Re: Neue Testversion 16.40b10
Sorry, das war etwas zu wenig Info. Es ging um Ebenen drehen, «Alt dreht "normal", Alt+Ctrl dreht "schnell", Alt+Shift dreht 90°». Unter genau diesem Eintrag finden sich weder Hinweise auf «ALT+Pfeil links/rechts» noch die genannten - zumindest in der Win-Version. Die aber vermutlich die selbe Textbasis hat wie die Mac, zumindest sind dort Mac-Screenshots drin, vermutlich, weil Win-User toleranter sind?Martin Huber wrote:Welche Tastenkürzel fehlen? Alt+Pfeil links und Alt+Pfeil rechts? Ich kann jetzt nur für die Mac-Version sprechen, aber da werden die beiden Tasten sowohl im Ebenenwerkzeug als auch im Beschneiden-Werkzeug erwähnt.
Was meine Installation betrifft, verhält es sich außerdem nicht so; ALT+CTRT schiebt den Rahmen nach links/rechts, ALT+SHIFT schiebt die untere rechte Ecke proportional nach oben/unten. Das habe ich mit Sicherheit nicht selbst eingestellt.
Generell ist die Hilfe unter Windows nur eingeschränkt benutzbar; sobald Umlaute ins Spiel kommen, wird der Text verhunzt. Sprich: Keine Möglichkeit, nach etwas zu suchen, Statt «Einführung» steht «Einführung» in der Themenliste.
Dass die MS-Hilfe mit UTF-8 nicht klar kommt, ist eher unwahrscheinlich; dafür wird sie in zu vielen Sprachen mit Sonderzeichen verwendet, die einwandfrei funktionieren. Das kann eigentlich nur mit UTF-8 zuverlässig funktionieren. Ich tippe eher auf eine Codierungsverwirrung des verwendeten Textprogramm für die Dokumentation. DAS ist nach meinen Erfahrungen nämlich nicht UTF-8 fähig. Zumindest benutze ich es deshalb nicht, wenn ich Texte portieren muss. Was den Hilfecompiler betrifft: Ihr verwendet das «Microsoft HTML Help 1.4 SDK» (http://msdn.microsoft.com/en-us/library ... s.85).aspx)? Dann sollten die genannten Effekte - bei korrekten HTML-Dateien - nämlich nicht auftreten. Ich habe kurzerhand mal eure CHM in HelpNDoc importiert und einfach wieder rausgeschrieben. Dann kann man auch nach "verflüssigen" suchen (und wird fündig...).Martin Huber wrote:Die Suchfunktion von Microsoft kann leider kein UTF-8. Ich habe keine Lust wegen der Unfähigkeit von Windows die Hilfe zu verkrüppeln, daher wird das wohl vorerst so bleiben.
Das ist fraglos der undankbare Teil einer Dokumentation. Allerdings: Wenn´s nirgends steht, wird´s niemand erfahren, selbst wenn man danach sucht. Womöglich müsste man die Hilfetexte mal generell überarbieten (Albtraum, ich weiß...) und sich ein "Präsentationskonzept" überlegen, dass z.B. für ein Werkzeug die verfügbaren (Standard-)Tastenbefehle (ohne Änderungen durch den Benutzer!) listet und eine Art "Blitzerklärung" sowie eine "Im Detail"-Erklärung bietet. Die Nutzung einer Dokumentation hängt direkt proportional von der Benutzbarkeit - sprich: Finden von gesuchter Information - ab. Je mehr man findet, desto weniger wird gefragt...Martin Huber wrote:Ich gebe dir recht, dass es optimal wäre, das bei jedem einzelnen Werkzeug zu dokumentieren. Aber gerade die Dokumentation des Ebenenwerkzeugs ist mittlerweile recht lang, so dass ich befürchte, dass die heute schon kaum einer mehr ganz durchliest.
Anderes Thema:
Bei den Schaltern für die Ansicht "ganze Höhe/Breite" fällt mir jedesmal auf, dass ein Dokument nicht korrekt zentriert wird. Bei Bildern scheint das (hab gerade nochmal ein bisschen rumgespielt) dagegen zu klappen.
Grüße
Norbert
Screencasts zu Photoline: http://www.buoa.de • Win 10x64 / PL64, immer die aktuellste Beta-Version.
-
- Betatester
- Posts: 3675
- Joined: Thu 26 Nov 2009 22:59
Re: Neue Testversion 16.40b10
Du hast natürlich völlig recht in Bezug auf den Pfusch mit den Tastenklicks. Das ist keine schöne Lösung - schon allein wegen der Zeitverzögerung, aber auch, weil man den Winkel wohl nicht so genau übertragen kann. Wobei ich mir nicht sicher bin, ob Wacom keine bessere Einbindung will, oder ob sich da Apple und/oder Microsoft querstellen. Aber das ist reine Spekulation.Martin Huber wrote:Die "Manie" von Wacom, anstelle der Gesten Tastenklicks zu verschicken, ist Pfusch. Wacom wird im Touch-Bereich nur dann eine Zukunft habe, wenn sie kompatibel zu den Gesten des jeweiligen Betriebssystems werden. Aber das wollen oder können sie nicht.bkh wrote:Wollt ihr ggf. auch die vom Wacom Touch unterstützen? Das Tablett sendet (beim Mac) beim Drehen einfach die Tastenkürzel CMD-L bzw. CMD-R. Zoom und Scrollen gehen mit dem Wacom ja schon.
Das mit dem Drehen ist mir im Prinzip auch nicht so wichtig, ich dachte nur, dass man da mit relativ geringem Aufwand Pluspunkte für PL sammeln könnte. Zumal es so scheint, als ob PS die Gesten des Wacom auch beim Drehen unterstützt, und es zumindest bei den Wacom-Foren immer wieder Nachfragen gibt, in welchen Programmen denn nun das Rotieren per Gesten funktioniert.
L.G.
Burkhard.
-
- Betatester
- Posts: 3675
- Joined: Thu 26 Nov 2009 22:59
Re: Neue Testversion 16.40b10
Das muss nicht der Grund sein - vorher gab es verschiedene landesspezifische Codepages, und auch damit funktioniert es, solange man nicht zu viele exotische Sprachen mixt.NoSi wrote:Dass die MS-Hilfe mit UTF-8 nicht klar kommt, ist eher unwahrscheinlich; dafür wird sie in zu vielen Sprachen mit Sonderzeichen verwendet, die einwandfrei funktionieren. Das kann eigentlich nur mit UTF-8 zuverlässig funktionieren.
Die HTML-Dateien der Mac-Hilfe sind einwandfreies UTF-8 und, wenn ich das richtig verstehe, identisch mit der Win-Version.NoSi wrote:Ich tippe eher auf eine Codierungsverwirrung des verwendeten Textprogramm für die Dokumentation. DAS ist nach meinen Erfahrungen nämlich nicht UTF-8 fähig.
Sind denn die dort exportierten HTML-Dateien weiterhin UTF-8-codiert? Im Header müsste dann sowas wieNoSi wrote:Zumindest benutze ich es deshalb nicht, wenn ich Texte portieren muss. Was den Hilfecompiler betrifft: Ihr verwendet das «Microsoft HTML Help 1.4 SDK» (http://msdn.microsoft.com/en-us/library ... s.85).aspx)? Dann sollten die genannten Effekte - bei korrekten HTML-Dateien - nämlich nicht auftreten. Ich habe kurzerhand mal eure CHM in HelpNDoc importiert und einfach wieder rausgeschrieben. Dann kann man auch nach "verflüssigen" suchen (und wird fündig...).
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> stehen, und die Umlaute müssten in einem Hex-Editor als zwei Zeichen erscheinen. (Wenn du magst, kannst du mal eine solche HTML-Seite mit Umlauten zippen und hier als Anhang posten.)
L.G.
Burkhard.
-
- Entwickler
- Posts: 4174
- Joined: Mon 18 Nov 2002 15:30
- Location: Bad Gögging
Re: Neue Testversion 16.40b10
Soweit ich das sehe, ist der neueste Help Compiler von Microsoft aus dem 1.3er Paket. Damit habe ich die Hilfe erzeugt. Die "HTML-Quelldateien" sind in jeder Hinsicht in Ordnung, da wir die mit einer eigenen Funktion aus der Hilfe Erzeugen (UTF-8-Tag im Header, korrekte Kodierung). Wenn du festgestellt hast, dass man mit einem anderen Tool eine Hilfe erzeugen kann, die funktioniert, liegt das Problem wohl am Microsoft Compiler. Dann sollte ich mich wohl nach einem anderen Tool umsehen.NoSi wrote:Dass die MS-Hilfe mit UTF-8 nicht klar kommt, ist eher unwahrscheinlich; dafür wird sie in zu vielen Sprachen mit Sonderzeichen verwendet, die einwandfrei funktionieren. Das kann eigentlich nur mit UTF-8 zuverlässig funktionieren. Ich tippe eher auf eine Codierungsverwirrung des verwendeten Textprogramm für die Dokumentation. DAS ist nach meinen Erfahrungen nämlich nicht UTF-8 fähig. Zumindest benutze ich es deshalb nicht, wenn ich Texte portieren muss. Was den Hilfecompiler betrifft: Ihr verwendet das «Microsoft HTML Help 1.4 SDK» (http://msdn.microsoft.com/en-us/library ... s.85).aspx)? Dann sollten die genannten Effekte - bei korrekten HTML-Dateien - nämlich nicht auftreten. Ich habe kurzerhand mal eure CHM in HelpNDoc importiert und einfach wieder rausgeschrieben. Dann kann man auch nach "verflüssigen" suchen (und wird fündig...).Gerhard Huber wrote:Die Suchfunktion von Microsoft kann leider kein UTF-8. Ich habe keine Lust wegen der Unfähigkeit von Windows die Hilfe zu verkrüppeln, daher wird das wohl vorerst so bleiben.
Gerhard