Ich suche den Speicherort, wo OSX 10.5.8 die Papiereinstellungen fuer die
Formate unter "Alle Drucker" (unter dem Menueeintrag -Seite einrichten)
gespeichert hat. Nicht den Speicherort der Benutzerdefinierten
Papierformate; den kenne ich.
Hintergrund:
Ich habe bemerkt, dass die Seitenraender der Papierformate, die unter "Alle
Drucker" stehen, groesser sind als die unter den speziell angewaehlten
Drucker.
Das kann bei Ausdrucken, besonders unter Acrobat, zu Fehldrucken fuehren;
manchmal fehlen Teile am Rand oder unten.
Natuerlich waehle ich das Format unter dem speziellen Drucker, nachdem ich
mehrere Fehldrucke hatte.
Aber mich interesiert, welche Einstellungen OSX 10.5 da hat und eventuell
will ich die dann aendern.
Ich danke Euch im voraus.
Viele Gruesse
Martin Jenniges
Warum fragt das Du das alle paar Monate? Siehe Thread rund um:
<http://groups.google.com/group/de.comp.text.pdf/msg/58eb995f9b449d61>
Gruss,
Thomas
die Antwort ist ganz einfach : weil die in deinem alten Posting
genannten Orte/Dateien auf meinem Mac nicht zu finden sind.
Treffen deine Angaben auch auf OSX 10.5.8 (PPC) zu ?
viele Gruesse
Martin
> die Antwort ist ganz einfach : weil die in deinem alten Posting
> genannten Orte/Dateien auf meinem Mac nicht zu finden sind.
Ach so.
> Treffen deine Angaben auch auf OSX 10.5.8 (PPC) zu ?
Klar. Aber natürlich nicht auf Deinem Mac. Dort ist alles ganz anders.
Gut' Nacht,
Thomas
Martin Jenniges <martinj...@skynet.be> wrote:
> die Antwort ist ganz einfach : weil die in deinem alten Posting genannten
> Orte/Dateien auf meinem Mac nicht zu finden sind.
Probiere mal den angegeben Pfad im Findermenu unter 'gehe zu Ordner'
einzugeben. Oder, wenn Du per Durchklicken an eine Datei stößt, wie der
nächste Ordner des Pfades, dann gehe mal im 'Rechte Maustastenmenu' auf
'Paket anzeigen' (oder so ähnlich).
Gruß
Volker
also, nachdem du deinen ausführliches Posting damals veröffentlicht
hast, habe ich mir den mu-commander installiert, damit ich auch
verborgene Dateien angezeigt bekomme. Anschliessend habe ich dann deine
angegebenen Pfade und Dateien gesucht, aber die Dateien nicht gefunden.
Leider kann ich nur sporadisch am Mac arbeiten, da er am Arbeitsplatz
ist und ich normalerweise nur 3 Tage in der Woche dort arbeite; und
natürlich bei viel Arbeit keine Zeit habe, nach den Dateien zu suchen;
sprich es kann einige Tage dauern bis ich nochmal alles überprüft habe.
Ist es wirklich unwahrscheinlich, dass die gesuchten Daten unter OSX
10.5.8 woanders stehen ?
viele Gruesse
Martin
(*)http://www.macupdate.com/app/mac/25716/hidden-way/
Gruß, Heinz
> Ich finde da "Hidden Way" super, ein 217KB Progrämmchen(*),
-chen-Verniedlichungsform für etwas, das über eine halbe Diskette füllt?
Tss!
Grüße
Götz
--
http://www.knubbelmac.de/
Diskette? 5,25" oder 3,5"? Gibt es noch aktuelle Mac/PC/Notebook/Netbook
mit solchen Laufwerken? Werden Disketten heutzutage noch (produktiv)
genutzt?
Gibt es kleinere Programme/Scripts, die gleiches leisten?
Ich weiss, dass man im Terminal (9,3MB(*)) mit
"defaults write com.apple.finder AppleShowAllFiles TRUE"
und folgendem "killall Finder" die Sicht auf versteckte Dateien
einschaltet. Zurück geht es dann mit "defaults write com.apple.finder
AppleShowAllFiles FALSE" und "killall Finder"
Das ist einfach nur unhandlich. Dann lieber einfach einen Klick auf das
"Hidden Way"-Symbol und die Ansicht wird entsprechend umgeschaltet.
Vielleicht gibt es eine ganz einfache und tolle Lösung via Automator
(3,4MB(*)), aber ich persönlich komme mit Automator nicht zurecht.
Wenn es die gibt, dann immer her damit!
Martin Jenniges erwähnte (4de8db25$0$14260$ba62...@news.skynet.be):
...habe ich mir den mu-commander installiert, damit ich auch verborgene
Dateien angezeigt bekomme...
(Download unter http://www.heise.de/software/download/mucommander/48095:
2,38 MB)
Gibt es auf Deinem Rechner Programme/Lösungen, die für dieses Problem
weniger Speicherplatz belegen?
(*) Mac OS X 10.6.7
Was soll dieser dämliche Kommentar von Dir?
Viele Grüße, Heinz
> Gibt es auf Deinem Rechner Programme/Lösungen, die für dieses Problem
> weniger Speicherplatz belegen?
Wir wissen nicht, was der freundliche Regular empfiehlt, aber wie wäre
es denn mit
<http://www.apple.com/downloads/dashboard/developer/hiddenfiles_matthans
en.html>?
69kB.
Nur so als Anregung.
Ein kleines Applescript reicht natürlich auch.
Und nur vom "nicht nutzen" wird Terminal.app auch nicht kleiner.
Aber Festplatten kosten ja auch nicht mehr die Welt...
cu
f
--
...ausserdem halte ich verdunkelte Heckscheiben für antisozial und dumm.
> Diskette? 5,25" oder 3,5"? Gibt es noch aktuelle Mac/PC/Notebook/Netbook
> mit solchen Laufwerken?
Jop.
> Werden Disketten heutzutage noch (produktiv) genutzt?
Ja.
> Was soll dieser dämliche Kommentar von Dir?
Tief durchatmen. Danke.
Das ist einfach nur gaga. Es gibt gewisse Orte am Mac, von denen man die
Finger besser läßt, _wenn_ man sich dort nicht adäquat bewegen kann bzw.
wenigstens eine Idee davon hat, was man gerade tut. Und "adäquat" meint
dann "in der Shell" bzw. in Terminal.app (und das eben nicht nur, um den
beschränkten Dateimanager "Finder" dazu zu bewegen, Dateien auf einmal
anzuzeigen, die er normalerweise aus gutem Grund vor unbedarften
Anwendern versteckt).
Gruss,
Thomas
da hab ich ja was ausgelöst mit meiner Bemerkung mit dem mu-commander ect.
Ich wäre froh, wenn mal jemand die Angaben von Thomas bezüglich des
Speicherortes von den Papierformaten unter 10.5.8 überprüfen würde. Bei
meinem Arbeitsplatz-Mac finde ich die Dateien nämlich nicht. :-(
viele Gruesse
Martim
Ich erlaube mir dezidierten Widerspruch. Ich finde den Finder extrem
übesichtlich und komfortabel, um eine bestimmte Datei zu suchen oder mir
einen überblick über eine Ordnerstruktur zu verschaffen, ja sogar um
eine Textdatei im Programm meiner Wahl zu öffenen. Als bekennender
Warmduscher arbeite ich eben lieber in einem grafischen Texteditor als
in vi. Und dazu ist es eben manchmal praktisch, den Finder anzuweisen,
alle Dateien zu zeigen. Und wenn man den Befehl so wenig braucht, dass
man ihn immer wieder vergisst und nachschlagen muss, ist so ein
Progrämmchen, welches das auf einen Klick erledigt, ganz nett.
Dass man sich in den versteckten Dateien mit angemessener Vorsicht
bewegt, setze ich jetzt einfach mal voraus.
Was willst Du denn mit "vi"? Ich verwende entweder vim (oder am Mac auch
mal BBEdit *mit passenden Einstellungen*) und empfehle Leuten, denen
die Bedienung von vim zu blöd ist, "nano -w".
> Und dazu ist es eben manchmal praktisch, den Finder anzuweisen,
> alle Dateien zu zeigen.
Der Finder disqualifiziert sich alleine schon dadurch völlig, daß er Dir
in jeden Ordner, in dem Du irgendwas an der _Ansicht_ im Finder änderst,
ungefragt eine .DS_Store in das Verzeichnis pappt. Der Finder ist kein
Tool, um irgendwas in Verzeichnishierarchien einfach nur nachzugucken,
weil er ohne spezielle Vorkehrungen Verzeichnisinhalte ungefragt
*modifiziert*. Ggf. tödlich, weil gewisse unixoide Softwares ganz eigene
Vorstellungen davon haben, was in welchem Verzeichnis liegt, ungeprüft
alle Dateien darin interpretieren oder laden und dann gar nicht starten
oder abschmieren (BTST... und das nicht nur einmal)
Dann zeigt Dir der Finder schonmal nur bei Vorliegen spezieller
Voraussetzungen überhaupt die richtigen Permission-Bits von Dateien an
(speziell "executable"), unterschlägt alles bzgl. ACLs und Extended
Attributes und in manchen Situationen (Netzwerk) sogar die wirklichen
Eigentümerschaften und Gruppenzugehörigkeiten (da greift im Finder dann
ein lustiges UID-/GID-Mapping)
> Und wenn man den Befehl so wenig braucht, dass man ihn immer wieder
> vergisst und nachschlagen muss, ist so ein Progrämmchen, welches das
> auf einen Klick erledigt, ganz nett.
Mei, soll sich doch jeder so oft und so tief ins Knie schießen wie er
lustig ist :-)
> Dass man sich in den versteckten Dateien mit angemessener Vorsicht
> bewegt, setze ich jetzt einfach mal voraus.
Wieso setzt Du das voraus? Der OP hat ganz konkret vor, das
Drucksystem zu "korrigieren". Und sucht nun nur nach 'ner Axt, mit
der er die Tür zum Unix-Keller aufkriegt.
Das da im Keller ist primitiver gammeliger Unix-Sch***, der am Besten
mit ebensolchen primitiven gammeligen Unix-Tools angefaßt wird und vor
allem mit wenigstens einer Idee von der dahintersteckenden Unix-Denke
("alles ist eine Datei", "keep it simple, stupid", etc.). Wenn man die
nicht hat und sich ausgerechnet über den Finder dem Kram nähert, dann
passieren halt die ulkigsten Dinge. Nur mal ein kleiner Auszug:
- die Datei wird mit anderen Zeilenenden gespeichert (Unix' "Line Feed"
vs. Mac "Carriage Return" bspw. -- ein steter Quell der Freude :-)
- die Datei wird mit anderem Encoding gespeichert, weil der Texteditor
eigene Vorstellungen davon hat (kann bei Konfig-Dateien spaßig werden)
- das Encoding bleibt gleich aber der Texteditor klatscht ein UTF-BOM
(<http://de.wikipedia.org/wiki/Byte_Order_Mark>) vorne dran. Damit ist
die Shebang-Line defekt, das Skript nicht mehr startfähig und der User
ratlos (weil man das BOM selbstredend nicht ohne weitere Verrenkungen
überhaupt sieht)
- Der Texteditor hat kreative Ideen bzgl. Zeilenumbrüchen und hackt die
Datei gekaputt
- Der Texteditor speichert das Dingens anschl. als formatierten Text ab.
- Beim Speichern werden dateiexterne Metadaten wie bspw. Permission-Bits
oder auch Gruppenzugehörigkeit "schnell mal eben" "angepaßt". Oder
gewisse Metadaten wie bspw. Type/Creator gelöscht.
- Mit dem Speichern pappen dann auf einmal Extended Attributes an der
Datei, die an anderer Stelle Probleme bereiten oder es
Gibt sicher noch 'ne Menge mehr. Das ist jetzt nur Zeugs, das mir schon
live und in Farbe begegnet ist. Nicht, daß mich sowas stören würde (so
manch abrechenbarer Manntag ist durch Analyse/Behebung der Folgen
solchen Zusammentreffens zwischen "klickibunti" und Unix-Unterbau, schon
zusammengekommen :-) aber man sollte das halt einfach im Hinterkopf
haben bzw. es gleich sein lassen, _wenn_ man nicht weiß, was man da
konkret eigentlich tut.
Manipulation von Text- bzw. Konfigurationsdateien sollte schon mit den
richtigen Tools erfolgen. Und da empfiehlt sich im Unix-Keller auch
primitves Unix-Werkzeugs, das eben *nur* den Dateiinhalt *als Text*
anfaßt und keine kreativen Ideen bzgl. sonstiger Änderung am Inhalt
mitbringt. Mit der Erweiterung für MacOS X, daß man Property Lists
sinnvollerweise nicht mit plain-text-Editoren anfaßt sondern Tools, die
das Format nativ verstehen, bspw. Apples Property List Editor oder
defaults(1).
Aber jeder nach seiner Façon... das Argument in obigem Kontext, daß
bisher immer alles gut gegangen ist, hat ja auch was für sich ;-)
Gruss,
Thomas
Wer Texteditoren schreibt, die vor UTF-8 codierten Dateien eine BOM
setzen, frisst auch kleine Kinder.
Nicht dass ich das von dem einen oder anderen Klickbunt-Editor nicht
erwarten würde.
Aber das Problem gibt's nicht nur unter MacOS X: vor einiger Zeit durfte
ich den Hex-Editor von UltraEdit auf einer Windoze-Büchse "geniessen".
Er zeigte mir die Bytes einer UTF-16-Kodierung an bei einer Datei, die
ich als UTF-8 gespeichert hatte. Ich war verwirrt – auch mit einem
anderen Editor gespeicherte Dateien waren alle UTF-16. Bis ich
misstrauisch wurde, und den C-Compiler angeworfen hab, kurz einen
Hexdump mit printf() auswerfend.
Alle Dateien waren korrekt; der "Hex-Editor" dieses "führenden
Textbearbeitungsprogramms" (Eigenwerbung) zeigt den Hexdump der internen
Darstellung im RAM an – und da konvertieren die Helden erstmal nach
UTF-16 in einem wstring...
Viele Grüsse,
VB.
--
Bitte beachten Sie auch die Rückseite dieses Schreibens!
> Was soll dieser dämliche Kommentar von Dir?
>>
>> Tief durchatmen. Danke.
Mach ich, entschuldige bitte, war an dem Tag sowieso irgendwie etwas
angefasst.
Gruß, Heinz
> <http://www.apple.com/downloads/dashboard/developer/hiddenfiles_matthans
> en.html>?
> 69kB.
> Nur so als Anregung.
Jepp, das ist definitv kleiner...
(Erbsenzähler Modus an)
Aaaber: dazu muss (das bei mir inaktive) Dashboard via
"/System/Library/CoreServices/Dock.app/Contents/Resources/DashboardClient.app"
(238KB) gestartet werden. Und schwubbdiwupp liegen wir bei 307KB, mal
vom belegten RAM abgesehen.
(Erbsenzähler Modus aus)
> Ein kleines Applescript reicht natürlich auch.
Wahrscheinlich schon, habe mich aber nie darum bemüht.
> Und nur vom "nicht nutzen" wird Terminal.app auch nicht kleiner.
> Aber Festplatten kosten ja auch nicht mehr die Welt...
Du hast völlig recht, Festplatten- und RAM-Größen spotten heutzutage
über solche Datenhäppchen.
Einen schönen Sonntag noch, Heinz
Es tut mir leid, dass ich an deinen Angaben gezweifelt habe; ich hab die
angegebene Datei gefunden.
An eine Aenderung traue ich mich aber nicht.
Viele Gruesse
Martin
Am 02.06.2011 14:22 Uhr schrieb "Thomas Kaiser" unter
<Thomas...@phg-online.de> in
slrniuf04p.2su...@phg-online.de:
Kann mir bitte jemand mitteilen wo die Benutzerdefinierten Papierformate gespeichert sind?
Vielen Dank.
Ihr Supportberater, Felix, möchte Ihnen Folgendes mitteilen:
Die selbst erstellten Papierformate werden in einer .plist-Datei gespeichert. Diese befindet sich unter folgenden Pfad:
Benutzer/ Library/ Preferences/ com.apple.print.custompapers.plist
der Vollständigkeit halber: