[GastForen Betriebsysteme und Dienste HELIOS .lay-Dateien statt 'layouts'-Ordner im HELIOS Admin von UB+

  • Suche
  • Hilfe
  • Lesezeichen
  • Benutzerliste
Themen
Beiträge
Moderatoren
Letzter Beitrag

.lay-Dateien statt 'layouts'-Ordner im HELIOS Admin von UB+

SimonL
Beiträge gesamt: 47

19. Mär 2008, 13:25
Beitrag # 1 von 6
Bewertung:
(3920 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo,
beim Test von UB+ im Demo-Modus fällt mir auf,
dass die Optionen ".lay" alternativ ´zu "'layouts'-Ordner" für den Layout-Namen
in den ImageServer Vorgaben des HELIOS Admin nicht mehr anwählbar sind.

Heißt das, dass die .lay-Alternative von UB+ nicht mehr unterstützt wird,
oder dass sie nur aus dem HELIOS Admin verschwand, aber über's Terminal nachwievor einstellbar (und weiterverwendbar) ist?

Was passiert beim Update von UB nach UB+ mit der vorherigen Vorgabe ".lay"?

Wo kann es Probleme mit der "alten", sprich ".lay"- Einstellung geben?
Wir haben nämlich "Softwares", die im selben Ordner die LAYs erwarten.

Danke für die auf Aufmerksamkeit,
simon
X

.lay-Dateien statt 'layouts'-Ordner im HELIOS Admin von UB+

Thomas Kaiser
  
Beiträge gesamt: 1299

19. Mär 2008, 14:10
Beitrag # 2 von 6
Beitrag ID: #342332
Bewertung:
(3906 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo,

Antwort auf [ SimonL ] beim Test von UB+ im Demo-Modus fällt mir auf,
dass die Optionen ".lay" alternativ ´zu "'layouts'-Ordner" für den Layout-Namen
in den ImageServer Vorgaben des HELIOS Admin nicht mehr anwählbar sind.


Das passiert hier ab HELIOS Admin 1.0.3 völllig unabhängig davon, ob man auf UB oder UB+ zugreift -- die Checkbox ist in jedem Fall weg. Allerdings wird das Verhalten unter UB noch zuverlässig durch die globale Pref Global/OPI/UseLayoutDir getriggert:

    http://www.helios.de/...ap8_doc.html#1088708

Antwort auf: Heißt das, dass die .lay-Alternative von UB+ nicht mehr unterstützt wird,
oder dass sie nur aus dem HELIOS Admin verschwand, aber über's Terminal nachwievor einstellbar (und weiterverwendbar) ist?


Bitte ausprobieren und hier berichten :-)

Ich könnte mir aber vorstellen, daß diesbzgl. nichts mehr geht, da Helios schon seit mindestens 1997 drauf hinweist, daß der Support für .lay-Grobbilder "demnächst" verschwinden wird. Und mit UB+ hat Helios ja auch neue "tolle" Gimmicks im Programm, bspw. ein Säubern des "layouts"-Ordners im Highlander-Stil ("Es kann nur eines geben"). Hat man dort bspw. ein TIFF-Lay von einem Feinbild erzeugen lassen und will nun noch bspw. ein EPS-Lay daneben legen, löscht der ImageServer heimlich still und leise das schon existente TIFF-Lay. Ich sehe schon wieder Workflows zusammenfallen wie Kartenhäuser und kann mir parallel aber gut vorstellen, daß einem Helios sowas als Feature verkaufen will :-(

Antwort auf: Wo kann es Probleme mit der "alten", sprich ".lay"- Einstellung geben?


Naja, Cross-Platform. Welches Windows-Programm kann was mit dem Suffix ".lay" anfangen?

Antwort auf: Wir haben nämlich "Softwares", die im selben Ordner die LAYs erwarten.


Ja, solche Altlasten haben auch viele unserer Kunden hier. Wir haben deshalb ein Tool im Programm, das sich auf Helios' layout-Events klemmt und die im "layouts"-Ordner befindlichen Dateien dann verschiebt -- sei es mit Suffix ".lay" neben das Original, sei es in eine komplett verschiedene Ordnerhierarchie, wo dann nur Lays liegen (Xinet-FPO-Style).

Viele unserer Kunden haben nämlich das Problem, daß deren Kunden mal lieber mit ".lay" arbeiten und andere mit zeitgemäßeren Lays (also passendes Suffix und im "layouts"-Ordner). Da die Helios-Preference nur global galt, hat man hier in jedem Fall Volume-spezifische Anpassungen durch ein nachgeschaltetes Programm vorzunehmen...

Gruss,

Thomas
--
http://kaiser-edv.de/


als Antwort auf: [#342316]

.lay-Dateien statt 'layouts'-Ordner im HELIOS Admin von UB+

SimonL
Beiträge gesamt: 47

20. Mär 2008, 10:20
Beitrag # 3 von 6
Beitrag ID: #342448
Bewertung:
(3862 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Danke Thomas,
deine ausführliche Behandlung meiner Fragen hat uns weitergeholfen.

Zu unseren, wenn auch bescheidenen doch erfolgreichen, Ergebnissen:
der UseLayoutDir-Befehl ist weiterhin anwendbar und bringt auch das erhoffte Ergebnis (.lay bei FALSE).

Trotzdem werden wir uns wohl langsam auf den Weg machen und mit layouts-Ordnern testen und auf ausgwählten Servern arbeiten. Hierzu vielleicht noch eine kurze Verständnisfrage, damit ich das Manual nicht noch weiter wälzen darf:
Ist es möglich im layouts-Ordner-Fall die Dateierweiterung für die lay-Daten von den Feindaten zu übernehmen oder ist man gezwungen mit "tif" resp. "eps" vorlieb zu nehmen?
(Damit würde der Grobdatenaustausch erleichtert.)

Ciao Simon


als Antwort auf: [#342332]

.lay-Dateien statt 'layouts'-Ordner im HELIOS Admin von UB+

rupfi
Beiträge gesamt: 71

20. Mär 2008, 18:35
Beitrag # 4 von 6
Beitrag ID: #342569
Bewertung:
(3846 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Oh Gott! Sie setzen es so langsam durch. Ich habe schon auf mehreren Helios-Treffpunkten auf dieses Problem aufmerksam gemacht. Die Helios/Promo Techniker meinten immer "...glauben nicht das es überhaupt Leute gibt die die Funktion der .lay nutzen..." Ich glaube es sind schon recht viele. Ich finde es einfach viel praktischer auf dem Server genau unterscheiden zu können ob diese Bilddatei nun ein HighRes oder ein 72dpi Layout Bild ist. Auch sind alle Externen Layouter bei uns daran gewöhnt ein .lay zu bekommen. Wie ist es zum Beispiel beim suchen von Bilddaten mit einem eindeutigen Namen? Bisher habe ich dann immer beide gefunden und über den Namen erkannt, muss man dann beim Layout-Ordner immer noch nach der Größe schauen um das HighRes-Bild herauszufinden?
Ich hoffe also es bleibt bei der Möglichkeit .lay zu erzeugen.
Grüße
Rupfi


als Antwort auf: [#342448]

.lay-Dateien statt 'layouts'-Ordner im HELIOS Admin von UB+

Thomas Kaiser
  
Beiträge gesamt: 1299

21. Mär 2008, 12:43
Beitrag # 5 von 6
Beitrag ID: #342624
Bewertung:
(3827 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo,

Antwort auf [ SimonL ] Ist es möglich im layouts-Ordner-Fall die Dateierweiterung für die lay-Daten von den Feindaten zu übernehmen oder ist man gezwungen mit "tif" resp. "eps" vorlieb zu nehmen?


Es ist so: Der ImageServer hängt an das Grobbild ein Suffix dran, wenn das Original auch eins hat, ansonsten nicht. Welches das Suffix das ist, hängt davon ab, in welchem Format das Grobbild erstellt wird. Normalerweise greift ja seitens ImageServer bisserl Eigenintelligenz insofern als standardmäßig entweder TIFF erzeugt wird oder falls es das Feinbild "nötig macht" (bspw. aktiver Freistellpfad), ein EPS. Daraus folgt dann halt "entweder ».eps« oder ».tif« am Dateinamen -- das eigentliche Problem ist aber das Dateiformat und das völlig unabhängig davon, ob das Grobbild nun "bild.lay", "layouts:bild.tif" oder "layouts:bild.eps" heißt)

D.h. es geht eigentlich weniger darum, was an den Dateinamen hinten dran kommt, sondern was im Grobbild drinsteckt. Hier kann man mittels zweier anderer Helios-Preferences Einfluß drauf nehmen (also daß das Format des Feinbilds für das Grobbild übernommen wird). Ob das alles sinnvoll ist, ob man gleich ein anderes default-Format vorgibt, etc. muß für jeden Workflow individuell entschieden werden. Die Helios-Defaults (also TIFF und ansonsten EPS, wenn Pfade oder sowas im Spiel) sind meines Erachtens nach grundsätzlich für einfache Workflows sinnvoll (weil dadurch die meisten Problemquellen vermieden werden, die durch sture Übernahme von Farbraum und Dateiformat aus dem Fein- ins Grobbild entstehen können, wenn die falschen Anwendungen im DTP-Workflow am Start sind).

Wenn man ausgefuchstere Workflows einsetzen will, dann muß man halt ggf. die Manuals wälzen, Trainings/Consultants buchen (keine Ahnung, ob sich in Promos neuem Seminar-Angebot sowas widerspiegeln wird) und an ein paar Stellen Feintuning betreiben.

Antwort auf: Damit würde der Grobdatenaustausch erleichtert.


Inwiefern? Auch mit dem ".lay"-Namenschema rennt man doch in das eigentliche Problem, daß Grob- und Feinbild hinsichtlich Farbraum/Dateiformat voneinander abweichen können und man daher beides nicht einfach so ohne Prüfung austauschen kann, wenn man sich nicht auf Standard-Formate einschießt (also bspw. vorgibt, daß alle Feinbilder nur als TIFF im CMYK-Farbmodell vorliegen dürfen, etc.)

Gruss,

Thomas
--
http://kaiser-edv.de/


als Antwort auf: [#342448]

.lay-Dateien statt 'layouts'-Ordner im HELIOS Admin von UB+

Thomas Kaiser
  
Beiträge gesamt: 1299

21. Mär 2008, 13:26
Beitrag # 6 von 6
Beitrag ID: #342636
Bewertung:
(3822 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo,

Antwort auf [ rupfi ] Die Helios/Promo Techniker meinten immer "...glauben nicht das es überhaupt Leute gibt die die Funktion der .lay nutzen..." Ich glaube es sind schon recht viele.


Ich kenne das ".lay"-Schema nur von paar Kunden meiner Kunden (alles Firmen mit der "Dynamik" von Ozeanriesen, die vor 10-15 Jahren mal irgendwelche Automatismen eingerichtet haben und an denen wenn möglich ohne Änderungen die nächsten 400 Jahre festhalten wollen)

Die ".lay"-Verfechter ignorieren relativ elegant, daß ".lay" nur und ausschließlich funktioniert, solange ausschließlich Macs im Spiel sind. Sobald auch nur ein PC mitspielen soll, muß man dem entweder die Lays umbenannt zur Verfügung stellen (super-simpel per Skript automatisierbar -- das nutzen auch einige unserer Kunden) oder aber auf das "layouts"-Schema ausweichen.

Das ist das eigentliche Problem (das mit dem "Feinbildname länger 27 Zeichen --> Lay unsichtbar" ist ja seit AFP 3.x keines mehr).

Wenn man sich diesem Problem nicht stellen muß (weil Mac-only oder mittels irgendeinem Mechanismus sichergestellt, daß die Windows-Layout-Plätze, die im Spiel sind, für ihre Plattform passend benamste Lays zur Verfügung gestellt bekommen), dann fällt es einem leicht, pro ".lay" zu plädieren. Ansonsten ist das ein simples K.O.-Kriterium, über das man nicht weiter nachdenken müsste.

Antwort auf: Ich finde es einfach viel praktischer auf dem Server genau unterscheiden zu können ob diese Bilddatei nun ein HighRes oder ein 72dpi Layout Bild ist.


Kann man doch ganz simpel, indem man guckt, wo das Bild eigentlich liegt.

Antwort auf: Auch sind alle Externen Layouter bei uns daran gewöhnt ein .lay zu bekommen.


Und die sterben alle, wenn sich das ändert und man ihnen vorher erklärt, daß auch da, wo kein ".lay" dran ist, ein Lay drin sein kann? Wink

Keine Ahnung, wie der Zugriff bzw. das "zur Verfügung stellen" der Grobbilder umgesetzt wird. Aber via WebShare kann man ganz simpel gewissen Usern nur die Erlaubnis erteilen, Grobbilder runterzuladen (könnte in WebShare sogar durch Anpassung des wsdownload.pl-Skripts dafür sorgen, daß die Suffixes on-the-fly beim Download nach ".lay" gewandelt werden, wenn man lustig ist), man kann das dito mittels jedem anderen beliebigen Automatismus, der Bilder zur Verfügung stellt, genauso machen. Meines Erachtens geht es hier eigentlich nur darum, Leuten mitzuteilen, daß aufgrund im graphischen Gewerbe heute üblichen Produktionsbedingungen, etwas, das die letzten 'zig Jahre so war, halt nun auf einmal anders ist. Wenn man den Grund dazu nachfüttert, dann wird sowas auch gefressen (zumindest meiner Erfahrung nach), auch wenn natürlich erstmal das übliche "So kann man nicht arbeiten"-Geschrei einsetzt...

Antwort auf: Wie ist es zum Beispiel beim suchen von Bilddaten mit einem eindeutigen Namen? Bisher habe ich dann immer beide gefunden und über den Namen erkannt, muss man dann beim Layout-Ordner immer noch nach der Größe schauen um das HighRes-Bild herauszufinden?


Wie suchst Du denn danach? Wenn Du das am Mac per Finder machst, dann schränk halt Deine Suche ein auf Dateien, die nicht den Creator-Code "GAGA" haben ("GAGA" ist ein Beispiel).

Es ist doch so simpel. Per default bekommen die Lays den Creator-Code von Photoshop zugewiesen, was immer wieder dazu führt, daß irgendwelche Schlaumeier Lays per Doppelklick öffnen, das Grobbild in Photoshop aufgeht, sie irgendwelche Änderungen dran machen und anschl. das Geflenne groß ist, weil das Grobbild kein Grobbild mehr ist (also auch kein OPI-Replacement stattfindet) sondern nur noch ein niedrig aufgelöstes und retuschiertes Feinbild ist.

Abhilfe total simpel möglich (und meines Erachtens in den meisten Workflows zu 100% wünschenswert).

Man setzt den Creator-Code für Lays auf irgendwas, bspw. "GAGA":

Code
HELIOSDIR </etc/HELIOSInstallPath  
$HELIOSDIR/bin/prefvalue -k Global/Opi/LayoutCreator -t str "GAGA"
$HELIOSDIR/bin/srvutil reconf opisrv


und fortan haben alle Lays eben diesen Creator Code (und dementsprechend kann man ihre Anzeige auch simpel im Suchdialog ausblenden lassen bzw. das gleich in den Finder-Defaults so einstellen). Wenn man sich nun noch ein Mini-Tool am Mac schreibt/zulegt, das für eben den Creator-Code registriert ist, dann geht das bei einem Doppelklick aufs Lay auf. Und das kann dann warnen, daß es sich um ein Grobbild handelt, anbieten, das dazugehörige Feinbild darzustellen oder in Photoshop zu öffnen, whatever. Setzen Kunden von uns alles zu ihrer vollsten Zufriedenheit ein und sehen keinen Nachteil von "layouts" vs. ".lay" bzgl. Deiner oben angebrachten Punkte bzgl. des "Handling"...

Zusammenfassend: Meiner Meinung/Erfahrung nach ist ein Festhalten an Grobbildern mit ".lay" in erster Linie einer eher konservativen Grundhaltung geschuldet, die auch nur funktioniert, solange ausschließlich Macs im Spiel sind und Windows-Clients außen vor bleiben bzw. ignoriert werden (gibt es ja vielerorts tatsächlich noch). Auch sind meistens Installationen betroffen, die an ".lay" hängen, bei denen eh nur ein verschwindend kleiner Teil der Helios-Features auch praktisch genutzt wird, d.h. das Meiste an Helios-Workflow-Potential brachliegt.

Ich hab es andererseits schon 'zigmal mitbekommen, daß Kunden von Kunden die Benamung mit ".lay" bis aufs Messer verteidigt haben (weil sie irgendwelche prähistorischen Bilddatenbanken oder Workflow-Lösungen oder meist am Schlimmsten intern erstellte Skriptchen, die bisserl Automatisierung ins Spiel bringen, im Einsatz haben) und sobald dann dort eine Abteilung mit Windows ins Spiel kam, dieses eherne Festhalten an ".lay" schneller gekippt werden sollte, als man schauen bzw. es umsetzen konnte. Insofern bin ich da inzwischen sehr skeptisch, was die Stichhaltigkeit der Argumente angeht, wenn sich das Fähnlein dann immer so dermaßen schnell dreht ;-)

Gruss,

Thomas
--
http://kaiser-edv.de/


als Antwort auf: [#342569]
X

Aktuell

PDF / Print
300_PDF20

Veranstaltungskalender

Hier können Sie Ihre Anlässe eintragen, welche einen Zusammenhang mit den Angeboten von HilfDirSelbst.ch wie z.B. Adobe InDesign, Photoshop, Illustrator, PDF, Pitstop, Affinity, Marketing, SEO, Büro- und Rechtsthemen etc. haben. Die Einträge werden moderiert freigeschaltet. Dies wird werktags üblicherweise innert 24 Stunden erfolgen.

pdf-icon Hier eine kleine Anleitung hinsichtlich Bedeutung der auszufüllenden Formularfelder.

Veranstaltungen
29.09.2022

IDUGS#85 Press2id

Zoom Meeting
Donnerstag, 29. Sept. 2022, 19.00 - 21.00 Uhr

Vortrag

Kennst du WordPress? Vielleicht. Verwendest du WordPress? Ja, klar! WordPress ist das am weitesten verbreitete System für die Erstellung von Webseiten. Um Webseitenbau soll es auf dieser IDUG aber nicht gehen. Gregor zeigt press2id (github.com/grefel/press2id). Seine Open-Source-Lösung für die Verbindung von Web und InDesign. Richtig gelesen: InDesign liest mithilfe von press2id die Inhalte der WordPress-Webseiten und generiert daraus Zeitschriften, Kataloge, Programmhefte oder Bierdeckel (das zeigen wir natürlich auch!). So wird die „Content First“ Theorie zu einer konkret anwendbaren Praxis, ohne gleich die ganz großen Räder zu drehen. Versprochen: Jeder kann nach der IDUG innerhalb kürzester Zeit Daten von WordPress nach InDesign importieren. Aber Achtung: Prinzipiell kann press2id aus jeder Website, oder besser Contentmanagementsystem (CMS) Daten auslesen und nach InDesign importieren! Spannend, oder? Danach geht es in die Praxis: Stefan hat die Webseite des Parktheater Iserlohn (parktheater-iserlohn.de) gestaltet. Die gedruckten Spielpläne (parktheater-iserlohn.de/interaktive-spielplaene) werden mit press2id realisiert. Wir schauen in den Maschinenraum und zeigen, wie die Lösung des Projekts realisiert wurde.

Nein

Organisator: InDesign Usergroup Stuttgart

Kontaktinformation: Christoph Steffens, E-Mailidug AT satzkiste DOT de

https://idugs85.eventbrite.de/

Von Wordpress nach InDesign
Veranstaltungen
08.11.2022

Frankfurt, Fraport Conference Center
Dienstag, 08. Nov. 2022, 13.30 - 18.00 Uhr

Seminar

Auf der Enfocus World Tour stellen wir Ihnen gemeinsam mit Enfocus die aktuellen Highlights von Enfocus Switch und dem Impressed Workflow Server (IWS) vor. Wir präsentieren Ihnen anhand typischer Aufgabenstellungen in einem modernen Produktionsbetrieb die Möglichkeiten, die Enfocus Switch für die Automatisierung und Standardisierung von Abläufen bietet. Wir haben sowohl für Produktionsverantwortliche als auch technisch Interessierte ein spannendes Programm vorbereitet, bei dem Sie sicherlich viel Neues erfahren werden, welches Sie in Ihrem eigenen Betrieb umsetzen können. Die Veranstaltung bietet darüber hinaus eine hervorragende Möglichkeit, sich mit anderen Anwendern und Workflow-Spezialisten auszutauschen und Antworten auf konkrete Aufgabenstellungen zu erhalten, welche Sie mit Hilfe von Enfocus Switch/IWS umsetzen möchten.

Wir sind jeweils an 2 Tagen in Frankfurt, Hamburg und München vor Ort. Der erste (halbe) Tag richtet sich in erster Linie an Betriebsleiter und Produktionsverantwortliche in Druckereien - ist also weniger technisch orientiert - sondern gibt einen Überblick zu den heutigen Möglichkeiten einer automatisierten Produktion.

Der zweite Tag (Switch Anwender-Treffen) richtet sich an bestehende Switch-Anwender und Administratoren.

Anmeldung und weitere Infos: https://www.impressed.de/schulung.php?c=sDetail&sid=310

Ja

Organisator: Enfocus/Impressed

Kontaktinformation: Silvia Noack, E-Mailsnoack AT impressed DOT de

https://www.impressed.de/schulung.php?c=sDetail&sid=310

Enfocus World Tour 2022