ThinSpace einfügen verändert Zeilenabstand

[RolloM]

Hallo allerseits,

Wenn man typographisch korrekt Abkürzungen wie "u.dgl.", "m.E.", aber auch Seitenzahlen wie 15ff. und dergleichen schreiben will, muss man das ja mit einem "Thin Space" tun. OOo Writer unterstützt diese - anders als zB FrameMaker - von Haus aus nicht, bzw. nur indirekt über Einfügen-Sonderzeichen und dann den Font Lucida Sans Unicode und das Zeichen &2009 (hex-Unicode). Vgl. http://www.oooforum.org/forum/viewtopic.phtml?t=45378, insbesondere http://www.ooowiki.de/LeerZeichen.

(Der im Wiki beschriebene non-breaking ThinSpace bei &202F, der noch besser wäre, funktioniert meines Wissens nicht - es kommt nur ein Viereck, zumindest hier unter Vista.)

Mit folgendem Makro kann man einen (eben: breaking) ThinSpace einfügen:

sub ThinSpaceEinfuegen
rem ----------------------------------------------------------------------
rem define variables
dim document as object
dim dispatcher as object
rem ----------------------------------------------------------------------
rem get access to the document
document = ThisComponent.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")

rem ----------------------------------------------------------------------
dim args1(1) as new com.sun.star.beans.PropertyValue
args1(0).Name = "Symbols"
args1(0).Value = Chr(&H2009)
args1(1).Name = "FontName"
args1(1).Value = "Lucida Sans Unicode"

dispatcher.executeDispatch(document, ".uno:InsertSymbol", "", 0, args1())

end sub

Das Problem ist nun, dass das Einfügen eines solchen ThinSpace den Zeilenabstand etwas vergrässert, zumindest in meinen Fussnoten. Die Zeilenabstände bei Fussnoten sind damit unterschiedlich, was inakzeptabel ist (Fussnoten mit 8 Pt., witzigerweise tritt das Problem beim 10 pt Fliesstext nicht auf). Offenbar hat die Lucida Sans eine unterschiedliche Höhe.

Kann man Writer irgendwie zwingen, immer den gleichen Zeilenabstand zu verwenden?

Gruss & danke

R.

[Karolus]

Hallo
Was tut sich denn bei:
...
dim args1(0)...
und auskommentierten 'args1(1).... zeilen ?

Gruß Karo

[RolloM]

Hallo
Was tut sich denn bei:
...
dim args1(0)...
und auskommentierten 'args1(1).... zeilen ?

Gruß Karo

Frag mich nicht solche Dinge - ich hab ein Sonderzeichen eingefügt und das mit nem Makro aufgezeichnet (da sind im Übrigen gar keine auskommentierten args-Zeilen, oder hab ich Tomaten vor den Augen...). Da die Aufzeichnungsfunktion fehlerhaft war (wie leider so oft) habe ich die Zeile args1(0).Value = Chr(&H2009) entsprechend angepasst (dort war der Bug).

Hab das Problem mit dem Zeilenabstand aber mittlerweile identifiziert. Im Fliesstext hatte ich vor Urzeiten bereits einen festen Zeilenabstand eingerichtet - das muss ich halt nun in den Fussnoten noch nachholen. Dann gehts. (Sorry für die dumme Frage also, darauf hätte ich vorher kommen müssen. Aber immerhin gibts jetzt ein ThinSpace-Makro im Forum )

[Karolus]

Hallo
Ich meinte damit ob das Makro abgeändert auf:
...
dim args1(0) as new com.sun.star.beans.PropertyValue
args1(0).Name = "Symbols"
args1(0).Value = Chr(&H2009)
'args1(1).Name = "FontName"
'args1(1).Value = "Lucida Sans Unicode"
....

..den Zeilenabstand nicht verändert ?
aber du hast ja jetzt eine Lösung gefunden

Gruß Karo

[RolloM]

Danke. Du hast Recht - warum einfach, wenns auch kompliziert geht . Und Deine Lösung vermeidet die Vergrösserung des Zeilenabstandes, was sicher besser ist.

Was aber eigentlich spannender wäre, wäre eine Lösung, die ohne solches "Gefrickel" auskommt. Wenn Unicode schon ThinSpace und NonBreaking ThinSpace definiert(hex 2009 und 202F - beim letzteren bitte nochmals nachsehen...), müsste man die doch auch selbstverständlich nutzen können. Ok, die in Windows enthaltene "Unicode"-Schrift Times New Roman kennt diese Zeichen nicht, der Font ist unvollständig. Nur die Lucida Sans enthält sie (deshalb hatte ich diese Schrift verwendet). Die Frage wäre zuerst, ob es eine für normalen Buchdruck taugliche Serifenschrift gibt, die diese Zeichen enthält. Eben um das Gefrickel zu vermeiden.

Und was ich mich derzeit noch mehr frage: Ich habe eine Titel-Formatvorlage, die mit Paragraphen funktioniert (§ 1, § 2, etc.). Nach dem §-Zeichen brauchst Du auch einen ThinSpace. Wie zum Teufel bekomme ich nun einen solchen ThinSpace in den nummerierten Titel? Im Moment sieht es herzzerreissend aus... Wenn das so weiter geht, muss ich die Sache noch manuell machen

Was ich in den letzten Tagen gemerkt habe: Writer ist nur knapp brauchbar, um lange Texte zu erstellen. Ich werde aufhören, den Leuten diese Software zu empfehlen, um ihre Dissertation zu schreiben. Denn wenn man zum typographischen Feinschliff kommt und anderen Dingen, die es für das Verfassen von Büchern braucht, kommt man früher seine Grenzen, als einem lieb ist.Von sauberen Lösungen für Dinge wie Querverweise, Randnoten, Inhaltsverzeichnis, flexibler Kapitelnummerierung und Suchfunktion (für Sonderzeichen!) sowie Index können wir nur träumen. Für Leute, die lange, saubere Buchtexte verfassen wollen, gibt es bislang aber auch sonst schlicht keine brauchbare Lösung. Word kann es nicht (ok, die lernen immer mehr dazu - unterdessen definitiv besser als Writer, sorry), Framemaker ist hoffnungslos veraltet (ich könnte Adobe würgen - die haben vor zehn Jahren Frame als einzige brauchbare Lösung für diese Aufgabe gekauft und lassen sie seither verrotten. Ok, genau besehen fehlt da seit eh und je nur die eine Funktion, die lange Fussnoten auf die nächste Seite umbricht, und eine grosse Bugfix-Session, die die ganzen Abstürze zum Verschwinden bringt), und auf Tex habe ich keine Lust (wir zählen nicht mehr das Jahr 1973). Das wäre DIE Marktlücke, aber offenbar erkennt man das in der Entwicklergemeinde nicht. Sind halt alles Programmierer und zu einem grossen Teil Nerds, und die kennen die Bedürfnisse der Leute da draussen zu wenig.

R.

[Stephan]

Was ich in den letzten Tagen gemerkt habe: Writer ist nur knapp brauchbar, um lange Texte zu erstellen. Ich werde aufhören, den Leuten diese Software zu empfehlen, um ihre Dissertation zu schreiben. Denn wenn man zum typographischen Feinschliff kommt und anderen Dingen, die es für das Verfassen von Büchern braucht, kommt man früher seine Grenzen, als einem lieb ist.Von sauberen Lösungen für Dinge wie Querverweise, Randnoten, Inhaltsverzeichnis, flexibler Kapitelnummerierung und Suchfunktion (für Sonderzeichen!) sowie Index können wir nur träumen. Für Leute, die lange, saubere Buchtexte verfassen wollen, gibt es bislang aber auch sonst schlicht keine brauchbare Lösung. Word kann es nicht (ok, die lernen immer mehr dazu - unterdessen definitiv besser als Writer, sorry), Framemaker ist hoffnungslos veraltet (ich könnte Adobe würgen - die haben vor zehn Jahren Frame als einzige brauchbare Lösung für diese Aufgabe gekauft und lassen sie seither verrotten. Ok, genau besehen fehlt da seit eh und je nur die eine Funktion, die lange Fussnoten auf die nächste Seite umbricht, und eine grosse Bugfix-Session, die die ganzen Abstürze zum Verschwinden bringt), und auf Tex habe ich keine Lust (wir zählen nicht mehr das Jahr 1973). Das wäre DIE Marktlücke, aber offenbar erkennt man das in der Entwicklergemeinde nicht.

Verärgert sein ist das Eine, Pauschale Kommentare das Andere ...

Die Anforderungen von Dissertationen unterscheiden sich schon einmal von denen von Büchern und Adobe FrameMaker ist im Übrigen für Bücher geeignet ansonsten würde kaum ein Buch existieren...
Was OOo ansonsten bei Inhaltsverzeichnissen falsch macht, weiß ich nicht und für lange Dokumente ist es bestens geeignet wenns um eine Fließtextverarbeitung geht - natürlich ist es nicht geeignet (und will das garnicht sein) wenn es um typischen Buchsatz geht oder layoutorientiertes Arbeiten.
Das Word sich das Ziel gestellt hätte für Buchtexte geeignet zu sein wußte ich nicht und glaube ich nicht, wenn es allerdings so wäre wäre Word keine Konkurrenz mehr weil OOo eben bewußt eine Fließtextverarbeitung ist und nicht mit satz- oder lauoutorientierten Programmieren konkurriert. Ich bin allerdings sicher das sich Word auch weiterhin als Fließtexttextverarbeitung versteht und deshalb direkte Konkurrenz von OOo bleibt.

Word zu loben und Writer zu kritisieren ist übrigens hier durchaus erwünscht und bedarf keines "Sorry", nur die Kritik muß dann inhaltlich auch stimmen, finde ich.

"DIE Marklücke" hat natürlich die Entwicklergemeinde längst erkannt, vielleicht kritisierst Du lieber ihre konkreten Bemühungen (Scribus) denn dort wäre sicherlich die kritische Begleitung eines Fachmannes willkommen, wer jedoch nicht einmal weiß was läuft sollte sich zuerst informieren.

Sind halt alles Programmierer und zu einem grossen Teil Nerds, und die kennen die Bedürfnisse der Leute da draussen zu wenig.

Ich bin zwar Keiner, aber Danke im Namen aller Programmierer - ob allerdings solche Bemerkungen sinnvoll sind erlaube ich mir zu bezweifeln.

Sinnvoll wäre sich zu informieren und sichmit seinen Fertigkeiten (die bei Dir augenscheinlich in Kenntnissen zur Textgestaltung bestehen) einzubringen, jedoch mit vorwärtsgerichtete Argumentation, die zu Lösungen führt und nicht nur die Leute verärget.


insgesamt:
OOo ist kein fehlerfreies Programm (und keineswegs ist das dadurch entschuldigt das andere auch nicht fehlerfrei sind oder gar dadurch das OOo OpenSource ist) und es kann jede Hilfe gebrauchen, auch die Deine wenn Du Fachmann bist und somit die Programmierer in 'schreibtechnischen Dingen' beraten könntest. Nicht fachmännisch (und verschenkte Zeit) ist es jedoch an einer konkreten Stelle über eine Fehl- (oder Nicht-) funktion des Programmes verärgert zu sein und sich mit halbwahren Kommentaren zu anderen Dingen Luft zu machen.

Inhaltliche Kritik an OOo finde ich im Übrigen sogar angenehmer als unberechtigte Lobhudelei (in der sich viele versuchen) - denn nur Kritik kann OOo auf Punkte aufmerksam machen die eine Verbesserung nötig haben, nur die Kritik muß meines Erachtens auch zutreffend sein.




Gruß
Stephan

[RolloM]

Hallo Stephan,

Ich bin seit etwa einigen Wochen daran, einem 200seitiges Buchprojekt den Endschliff zu geben, nachdem ich zuvor 18 Monate lang daran gearbeitet habe (alles mit OOo Writer). Und wie man dem Tonfall meines Postings entnehmen kann, ärgere ich mich grün und blau. Mein erstes Buchprojekt habe ich übrigens vor acht Jahren mit Frame geschrieben.

Stichwort eigene Beiträge: Ich habe mich seit Jahren immer und immer wieder in Issuezilla geäussert und wohl zwei oder drei Dutzend Fehlermeldungen und Verbesserungsvorschläge abgesetzt und bei anderen den Senf dazu gegeben (ich habs unter dem gleichen Pseudonym getan wie hier, kannst Dir meine Kommentare ja mal anschauen - der Tonfall war im übrigen allermeistens freundlich...).

Resultat der ganzen Mühe: Nur gerade EINER meiner Vorschläge wurde umgesetzt, und zwar der läppischste: Die kurze Meldung, wonach das "l" im Tabelle-Menü verlinkt sein müsse, damit man es mit der Tastatur aufrufen kann... Der ganze Rest der mühseligen Arbeit für die Vorschlage landete auf dem Müllhaufen der Nerds. Stichwort Nerds: Man ging mittlerweile beispielsweise so weit, die Unterstützung Alt-Taste in OOo unnötig zu erklären und den seit Jahren offenen Issue dazu zu schliessen. Ich befürchte, der Grund dafür liegt darin, dass diese Taste unter Linux für Anwendungen nicht zur Verfügung steht und es daher aus Nerd-Sicht völlig unnötig ist, sie zu unterstützen Dass 95% der OOo-Anwender Windows verwenden und diese Taste extrem sinnvoll wäre, um ENDLICH die dringend nötige Tastatur-Kompatibilität mit Word herzustellen, weil nur so die ganzen Leute bedient werden können, die einmal mit Word und einmal mit OOo arbeiten müssen, wird schlicht ignoriert. Ich habe manchmal sogar den Eindruck, dass man Kompatibilität sogar absichtlich vermeiden will. Sorry, sowas ist doch einfach idiotisch...

Scribus kenne ich in der Tat nicht - mir geht es aber auch nicht um ein DTP-Programm (Kann man damit 300 Seiten schreiben, mit Querverweisen, Fussnoten, automatisch nummerierten Titeln, einem Inhaltsverzeichnis und einem Index?), sondern um etwas wie FrameMaker. Zudem müsste ich mein Dokument von Writer nach Scribus konvertieren können, ohne danach drei Wochen Arbeit zu investieren. Und daran glaube ich nun malnicht...

Frame war vor 10 Jahren in der Tat brauchbar und konkurrenzfähig. Abgesehen davon, dass es noch im Jahr 2000 keinen Mehrfach-Undo unterstützte, die Rechtschreibprüfung und die automatische Silbentrennung komplett unbrauchbar und instabil waren und Fussnoten nicht umbrochen wurden. Bis heute ist das erste Problem gelöst, aber der Rest noch nicht, und das Programm ist instabil und hat ein look&feel wie Word 95.

So. Der Kropf ist leer. Vielleicht liest ja sogar einer mit, der sich mal mit der Frage der grossen Buchprojekte auseinandersetzen will...

R.

[Stephan]

Ich bin seit etwa einigen Wochen daran, einem 200seitiges Buchprojekt den Endschliff zu geben, nachdem ich zuvor 18 Monate lang daran gearbeitet habe (alles mit OOo Writer). Und wie man dem Tonfall meines Postings entnehmen kann, ärgere ich mich grün und blau.

Bloß genau das ist doch der Fehler, Du benutzt ein ungeeignetes Programm für diese Aufgabe und bist dann verärgert. Ich hätte dir SOFORT von OpenOffice.org für ein BUCHprojekt abgeraten weil OOo dafür nicht geeignet ist, dafür nicht geeignet sein will.

Das, das Du in OOo ein falsches Programm für die konkrete Aufgabe benutzt, ist doch der Kerngrund Deiner Probleme, Fehler innerhalb von OOo (die ja gar niemand bestreitet) kommen noch hinzu, sind aber hierbei letztlich nur 'nebensächlich'.

Was Du tust ist schlicht mit einer Zange einen Nagel in die WAnd zu schlagen und dich dann zu beschweren das du Dir dabei auf die Finger haust - nimm gleich einem Hammer dann geht das besser, aber sage nicht die Zange sei schuld, sie ist es nämlich nicht, nur sie sie für die Aufgabe nicht geeignet.

Resultat der ganzen Mühe: Nur gerade EINER meiner Vorschläge wurde umgesetzt, und zwar der läppischste: Die kurze Meldung, wonach das "l" im Tabelle-Menü verlinkt sein müsse, damit man es mit der Tastatur aufrufen kann... Der ganze Rest der mühseligen Arbeit für die Vorschlage landete auf dem Müllhaufen der Nerds.

Und wie kommst Du zu dieser Einschätzung?
Das was Du hier beschreibst erleben Viele so ähnlich und das vielfach nur weil uns die Leute fehlen. Nicht, oder nur in Ausnahmefällen, erlebe ich jedoch das issues falsch behandelt werden etwas ganz Anderes sind jedoch lange Verzögerungen.
Wo wirklich Fehler passiert sein sollte, kritiere das im issue oder thematisiere es auf Projektmailinglisten, hier im Forum ist es wirkungslos. 'Nichtbehandlung' von issues, die Du zu sehen glauben meinst, liegt jedoch bei zeitlicher Verzögerung nicht vor, es gibt issues die sofort angenommen werden und wo jeder Willens ist sie umzusetzen, nur trotzdem ergeben sich dann Zeiten von >2 Jahren, weil nicht genügend Leute da sind.
Das im Gegensatz dazu manche Dir unwichtig erscheinenden Dinge, u.U. relativ schnell umgesetzt werden hat meist objektive Gründe die sich Dir aber nur erschliessen wenn Du Dich genauer mit der allgemeinen Handhabung von issues beschäftigst.

Ich hoffe sehr das Du meine Aussagen nicht als Verteidigung eines Zustandes verstehst, der auch mir nicht gefällt, der niemandem im Projekt gefällt der aber so ist wie er ist wenn es nicht mehr Leute gibt.
Eines jedoch an Deiner Aussage ist grundfalsch, nämlich die Annahme von 'Dillitantismus', ich habe nur sehr selten erlebt das issues falsch bewertet wurden (also beispielswise unberechtigt zurückgewiesen) und wo das doch einmal vorkommt solltest Du schlicht dranbleiben und nachhaken.
Viele Dinge sind hingegen nicht so eindeutig zu beantworten wie sie Dir scheinen mögen, denn ich kenne durchaus leider auch issues die trotz aller professionellen Betrachtung (oder gerade deshalb) sehr lange zur Umsetzung brauchen, weil sie inhaltlich umstritten sind - "umstritten" mit bester Absicht, nämlich im Ringen um eine optimale Lösung.

Und bewerte bitte das OOo-Projekt nicht falsch, wir sind kein Wirtschaftunternehmen, wir können nicht zusätzliche Leute einstellen wo wir merken das sie fehlen, wir sind rein auf die Hilfe Freiwilliger angewiesen, seien es Freiweillige wie du sie dir vorstellst (also Personen die in ihrer Freizeit mitarbeiten) oder seien es Firmen die Geld oder Personal zur Verfügung stellen und die OOo damit innerhalb und außerhalb des OOo-Projektes unterstützen.

Zu allen diesen Aussagen betone ich nochmals das ich überhaupt nicht die Absicht habe das OOo-Projekt ungerechtfertigt zu verteidigen, ich wehre mich hier ausschließlich gegen den Vorwurf der Unfähigkeit von Beteiligten, solange Du keine genauen Fakten nennst.
Lange Zeitverzögerungen bei der Umsetzung von Features, Nutzerwünschen u.Ä. sind jedenfalls zunächst nur Ausdruck von Personalmangel, wo es hingegen echte handwerkliche Fehler bei der Bearbeitung von issues gibt gehören die natürlich auf die Tagesordnung und du solltest das public machen.
Nach meiner (etwa 5-jährigen) Projekterfahrung sind echte handwerkliche Fehler bei der issue-Bearbeitung aber selten und sie werden um so seltener sein je häufiger es gelänge das Fachleute für bestimmte Themen (wie z.B. Du hier) zu uns ins Projekt finden. Das würde ich mir wünschen, denn DEine (pauschale und ungerechte) Kritik hier im Thread bringt die Dinge nicht voran, die Fachkunde die jedoch hinter DEinen Worten sichtbar ist würde ins Projekt geleitet jedoch sicherlich hilfreich sein.

Frame war vor 10 Jahren in der Tat brauchbar [...]

er ist es heute noch...

Etwas ganz Anderes wäre wenn Du so verstanden werden willst als wenn Computer und Software heutzutage generell noch nicht genügend gereift sind, denn darüber kann man durchaus reden.

Allein hier eine Situation zu zeichnen als wenn Framemaker erstens zwar noch das am besten funktionierende Programm sei, zweitens aber trotzdem unbrauchbar entbehrt praktisch jeder Grundlage.



Gruß
Stephan