[de-dev] Fehler in OO Calc 2.0rc1
Hallo, ich bin mir nicht sicher, ob ich hier richtig poste, bitte ggf. weiterleiten und mich informieren. Ich habe in OpenOffice Calc 2.0rc1 folgenden Fehler entdeckt: Format -> Seite... -> Hintergrund -> Als Grafik Ist das Dokument im A4-Querformat angelegt, erscheint zwar in der Vorschau "Format -> Seite... -> Seite" das Blatt im Querformat, aber im oben genannten Reiter "Als Grafik" erscheint das Vorschaubild weiterhin im Hochformat. Gruß, Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-dev] OOo Calc 2.0rc1 - falsche Zeilenhöhe
Hallo, ich habe folgenden Fehler in OOo Calc 2.0rc1 festgestellt (oder habe ich etwas übersehen/falsch eingestellt?): Die Zeilenhöhen stimmen nicht exakt. Beispiel: Bei mir sind alle Zeilen auf exakt 0,40cm Höhe eingestellt. Demzufolge müsste eine 0,4cm hohe Grafik an der Position 800,00cm (Oberkante Grafik) exakt die Zeile 2001 überdecken. Tatsächlich sitzt Zeile 2001 aber wesentlich weiter höher, und zwar auf Position 796,97cm (Oberkante). Tatsächlich ist also jede Zeile statt der angegebenen 0,40cm nur 0,39849cm hoch. Noch deutlicher wird es, wenn die Zeilen 1,00cm hoch sind. Zeile Nummer 2001 sitzt nun auf der Höhe 1965,87cm statt auf 2000,00cm. Hier ist jede Zeile nur 0,982935cm hoch statt 1,00cm. Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-dev] OOo Calc 2.0rc1 - falsche Zeilenhö he
Hallo Stefan, Die Zeilenhöhen stimmen nicht exakt. Was heißt schon exakt? Nach Deiner Erhebung liegt der Fehler bei rund 1 Prozent. Das ist nach meinem Empfinden sehr wohl exakt. Im Falle eines CAD-Programms wäre ich zwar nicht zufrieden, aber Calc erfüllt andere Zwecke. Ohne, dass ich den Quellcode gelesen hätte, habe ich auch eine Erklärung, wie es zu Abweichungen kommen kann: Die Zeilenhöhe wird "intern" bestimmt nicht in cm verarbeitet, sondern in irgend einer anderen Einheit. Beim Übergang zwischen den Einheiten kommt es zwangsläufig zu Rundungsfehlern. Das ist ganz normal. Wenn man eine Buchhaltung in EUR macht und dann die Bilanzpositionen in US$ umrechnet, dann geht die Bilanz in Dollar am Ende auch um ein paar Cent nicht auf. Nochmal zu den Größenordnungen: Du bemängelst, die Zeilen seien 0,17 mm zu klein. Das ist etwa die Hälfte eines einzelnen Pixels auf meinem TFT-Monitor. :-) Viele Grüße Stefan Ich erstelle einen Katalog mit Calc, und hier ist dieser Fehler leider recht offensichtlich und (in meinem Fall) nicht umgehbar. Vielleicht kann ich den Fehler aber umgehen, wenn ich z.B. auf eine andere Einheit umschalte? Vielleicht ist es aber auch garnicht schwer, diesen Fehler im Programm zu beheben. So oder so ist es (imho) eine Ungenauigkeit, die ich einfach mal bekanntgeben wollte. Ansonsten muß ich dann leider doch zu einem DTP-Programm wechseln. Grüße, Dennis
[de-dev] Fehler in OOo 2.0 Calc, PDF einfügen
Guten Morgen, folgenden Fehler konnte ich gerade in OOo 2.0 Calc feststellen: Ein vorgegebenes PDF (erstellt mit OOo Writer) im Format 130,5mm x 32,1mm wollte ich in OOo Calc importieren. Hier erhält es aber dann die "Originalgröße" von 97,9mm x 24,1mm. Durch einfaches Vergrößern auf die ursprüngliche Größe sieht das PDF dann nicht mehr unbedingt hübsch aus, stellt also keine Alternative oder Workround zu dem Problem dar. Meine Vorgehensweise: Neues OOo-Dokument Calc -> Einfügen, Objekt, OLE-Objekt... -> Aus Datei erstellen, Mit Datei verknüpfen, Suchen, OK -> Rechts Maustaste auf das eingefügte Objekt, Position und Größe -> falsche Größe wird angezeigt. Ist das Problem bekannt? Werden ggf. weitere Informationen benötigt? Gruß, Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-dev] Re: OpenOffice 2.0
Hallo, ich hatte ja ein paar Fehler und anregungen genannt die für mich eine Grosse Rolle spielen .. ich wollte mal fragen wann da eine Verbesserung kommt oder ob die überhaupt in der 2.0 kommen wird.. Fragen wie z.b. Dieser Passwort schutz etc. oder diese Farben Issuezilla ist dein Freund. Such nach den Fehlern die du beschreibst. Existiert ein Issue dann trägst du dich ins CC ein. Existiert kein Issue, dann erstellst du einen. Egal wie, du wirst dann immer auf den neuesten Stand gebracht sobald jemand einen Kommentar im Issue hinterläßt. Hier der direkt Link: http://user-faq.openoffice.org/servlets/ProjectIssues Gruß, Dennis
Re: [de-dev] OOo Calc 2.0rc1 - falsche Zeilenhö he
Hallo Bernhard, Die Zeilenhöhen stimmen nicht exakt. Was heißt schon exakt? Nach Deiner Erhebung liegt der Fehler bei rund 1 Prozent. Das ist nach meinem Empfinden sehr wohl exakt. Im Falle eines CAD-Programms wäre ich zwar nicht zufrieden, aber Calc erfüllt andere Zwecke. Ohne, dass ich den Quellcode gelesen hätte, habe ich auch eine Erklärung, wie es zu Abweichungen kommen kann: Die Zeilenhöhe wird "intern" bestimmt nicht in cm verarbeitet, sondern in irgend einer anderen Einheit. Beim Übergang zwischen den Einheiten kommt es zwangsläufig zu Rundungsfehlern. Das ist ganz normal. [...] Ich erstelle einen Katalog mit Calc, und hier ist dieser Fehler leider recht offensichtlich und (in meinem Fall) nicht umgehbar. Vielleicht kann ich den Fehler aber umgehen, wenn ich z.B. auf eine andere Einheit umschalte? Vielleicht ist es aber auch garnicht schwer, diesen Fehler im Programm zu beheben. So oder so ist es (imho) eine Ungenauigkeit, die ich einfach mal bekanntgeben wollte. Ansonsten muß ich dann leider doch zu einem DTP-Programm wechseln. Ich kenne mich mit der Katalogerstellung nicht aus, doch weshalb ist für Dich Calc eine Alternative zu einem DTP-Programm? Vor allem aufgrund des Preises. Ich würde auch gern mit Quark und Zusatzprogrammen arbeiten, das sprengt allerdings ganz deutlich den Kostenrahmen. Da der Katalog auch auf den meisten Seiten sehr ähnlich aussieht ist es Calc einfacher für mich, ein schnelles einheitliches Layout zu schaffen. Meines Erachtens sind die Layout-Möglichkeiten in Writer deutlich besser und einfacher anzuwenden. Mit einer Tabelle in Writer kannst Du Deine Grafiken seitenabhängig positionieren - das ist sicherlich genauer als über tausende von Tabellenzeilen hinweg. Ich bin inzwischen einfach dazu übergegangen, pro Katalogseite eine Tabelle anzulegen. Macht mir zwar die Arbeit etwas aufwendinger, aber der Fehler wirkt sich nicht mehr aus. Mit Writer hatte ich einiges probiert und getestet, leider klappt das nicht so wie von mir gewünscht. Trotzdem danke für den Tip. Auch wenn Du meinst, in Deinem Fall sei der Fehler nicht umgehbar - vielleicht gibt es doch einen anderen Ansatz, der Dein Vorgehen mit der Aufsummation von 2000 Rundungsfehlern vermeiden kann.Vielleicht kann Dir hier jemand weiterhelfen, wenn Du berichtest, was genau Du darstellen willst. Ich möchte Grafiken an exakt vorgegebenen Stellen auf der Seite plazieren. Damit die Grafiken nicht beim Einfügen oder Löschen von neuen Zeilen oder Spalten verrutschen verankere ich sie direkt an der Seite und gebe die errechneten (vorgegebenen) Koordinaten direkt ein. In meinem Beispiel handelt es sich um viele untereinander angeordnete A4-Querseiten. So eine Querseite ist 210mm hoch. Dementsprechend muß eine Grafik, die an der 11. Seite genau an der oberen Kante plaziert werden soll auch an der Position 2100mm angeordnet sein. Und genau bei diesen Aktionen hatte ich den Fehler festgestellt: Daß eben die Tabellenzeilen, die an exakt der gleichen Stelle sein sollten (z.B. mit der Seitenüberschrift) und die von Hand festgelegte und plazierte Grafik (z.B. Hersteller-Logo, aber auch Falzmarken und viele andere Grafiken) deutlich voneinander abweichen. Und zwar um so mehr, je mehr Tabellenzeilen bis dahin exestieren. (Übrigens: Bei mir beginnt Zeile 2001 mit Zeilenhöhe 1 cm an der Position 1992,74 - also an einer anderen Stelle als bei Dir. Damit liegt das mE nicht in erster Linie am Programm, sondern an der Hardware: Hier Laptop mit 12 Zoll-Monitor und 800x600er Auflösung unter Win98SE Dass eine andere Einheit das Problem nicht löst, hast Du ja bestimmt schon selbst probiert.) ja. (bei mir: Win2K, 1200 x 1024) Herzlichen Gruß Bernhard Gruß, Dennis
Re: [de-dev] Fehler in OOo 2.0 Calc, PDF einfügen
Hallo Regina, Meine Vorgehensweise: Neues OOo-Dokument Calc -> Einfügen, Objekt, OLE-Objekt... -> Aus Datei erstellen, Mit Datei verknüpfen, Suchen, OK -> Rechts Maustaste auf das eingefügte Objekt, Position und Größe -> falsche Größe wird angezeigt. Das liegt aber nicht am Import in OOo. Die pdf-Datei kommt auch beim Import in andere Programme, hier CorelDraw, mit falscher Größe an. mfG Regina Meine CorelDraws 7 und 9 importieren das PDF leider garnicht (richtig). MS-Word 2002 importiert das PDF in exakt der gleichen falschen Größe wie OOo. Interessanterweise importiert aber Adobe Photoshop 6 das PDF richtig. Daher denke ich schon, daß es an einem Import-Filter hängt. Oder ggf. ist das generierte PDF von OOo auch nicht "normgerecht"? Um das ganze zu umgehen (wenn vielleicht auch nicht auf Dauer): Wenn man in Writer alles 33,3% größer als gewollt einstellt, dann erreicht das pdf beim Importieren die gewünschte Größe. In meinem Fall wird aus dem gewünschten Seitenformat in Writer von 13,05cm x 3,20cm einfach 17,4cm x 4,27cm und aus der Schriftgröße 8pt wird 10pt. (13,05 geteilt durch 0,75 ergibt 17,4 etc.) Noch einen schönen Sonntag, Dennis
Re: [de-dev] Fehler im OpenOffice 2.0
Johannes Loxen schrieb: OpenOffice 2.0 unter Linux x86 hat folgendes Fehlverhalten auch in der Final: Tabellen: - Wenn man in einer Tabelle Zellen mit unterschiedlichem vertialen Alignment hat (Oben, Mitte, Unten), kann man nicht alle Zellen markieren und gleichzeitig auf "Oben" setzen, sondern nur mit Zellen gleichen Typs. Bei OpenOffice 1.1.x ging es ohne Probleme alle Zahlen auf "Oben" zu stellen, unabhängig vom gegenwärtigen Zustand. OOo 2.0 Windows 2000 x86, kann das Problem nicht nachvollziehen. Ändert man in einer Tabelle, in der alle Zellen auf "Oben" eingestellt sind einen Zahlenwert und verlässt Die Zelle per , dann wird die Zelle auf Alignment "Unten" gestellt und die Zellen-Einträge wechseln nach unten. Dies war auch schon bei Version 1.1.X so, so dass man nach jedem Ändern einer Zahl in einer Spalte die Tabelle neu einstellen musste - alles markieren und auf "Oben" stellen, was nun in 2.0 nicht mehr geht ?! :-) OOo 2.0 Windows 2000 x86, klappt bei mir auch ohne Probleme. Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-dev] OpenOffice 2 Tastaturkuerzel und Hilfe
Hallo Ulrich, Du kannst folgendermaßen den ShortCut anpassen: : "Extras" - "Anpassen..." - Reiter "Tastatur" : In der oberen Übersicht die Tastenkombiantion "Strg+Umschalt+F" anwählen. : Rechts aus "Löschen" klicken : In der oberen Übersicht die Tastenkombiantion "Strg+F" anwählen. : Im Auswahlfeld "Bereich" unten links "Format" auswählen : Im Auswahlfeld "Funktion" unten mittig "Fett" auswählen : Oben rechts auf "Ändern" klicken : Mit "OK" bestätigen. Gruß, Dennis Ulrich Dierssen schrieb: Sehr geehrte Damen und Herren, ich habe leider keine Ahnung, ob dies die richtige Ansprechstelle ist. Aber beim Arbeiten mit OpenOffice 2 ist mir aufgefallen, dass man ergonomische Tastaturkürzel, z.B. "Strg+f" für fett in ein völlig unergonomisches "Strg+Umsch+f" geändert hat. Da ich selber viel mit den Tastaturkürzeln arbeite, war für mich die einzige Möglichkeit, entweder auf das meinem Rechner beiliegende Microsoft Works umzusteigen, bei der alten 1.1.5 Version zu bleiben oder, so wie ich es letztlich gemacht habe, die Tastaturkürzel entsprechend meinen Bedürfnissen und entsprechend der Aussage der Hilfe, die noch die alten Tastaturkürzel beschreibt, anzupassen. Ein Fehler, der sowohl in der Testversion des StarOffice 8 als auch im OpenOffice vorhanden ist! Vielleicht kann man ja mal darüber nachdenken, statt Microsoft nachzuäffen, lieber mit ergonomischen Arbeiten Microsoft-User zum Umsteigen zu bewegen. Mit freundlichen Grüßen Ulrich Dierßen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-dev] Startseite von de.openoffice.org
Hallo Volker, Volker Merschmann schrieb: Der Entwurf ist auf http://de.openoffice.org/newhome.html online. Wir bitten um Diskussion und Abstimmung per +1/-1 Gruß Volker +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-dev] Titel in Fensterleiste?
Hallo Thomas, Thomas Krumbein schrieb: Hey, in Version 1.1.x wurde der Dokumententitel in der Fensterleiste oben angezeigt - soweit vorhanden. In den Testversionen (so mXX) müsste das auch noch funktioniert haben. Gerade kam eine Meldung im Forum, dass es aktuell (Final 2.0.0) nicht mehr geht. Hab ich ausprobiert und kann das bestätigen (2.0.1 - Win XP). Bug oder Feature? Weiss das jemand? Gruss Thomas Windows 2000, OOo 2.0 Calc und Writer: Dokumententitel steht in der Fensterleiste. Alles ok. Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-dev] Bug/Feature: Writer Tabellenzellen Verschmelzung/Teilung
Hallo Guido, Guido Ostkamp schrieb: Hallo, ich habe mal ein bißchen mit Tabellen in Writer herumexperimentiert. Gegeben sei folgende 3x3 Tabelle: A1 B1 C1 A2 B2 C2 A3 B3 C3 1. A2 und B2 markieren und Zellen verschmelzen 2. Entstehende Zelle markieren und Zelle wieder trennen (in 2 Zellen, sieht dann aus wie vorher) 3. B2 und C2 markieren und Zellen verschmelzen -> funktioniert reibungslos MS Word 2002 auf Win2k: klappt auch wie beschrieben. aber: 1. B2 und B3 markieren und Zellen verschmelzen 2. Entstehende Zelle markieren und Zelle trennen (in 2 Zellen, sieht dann aus wie vorher) 3. B1 und B2 markieren und Zellen verschmelzen -> funktioniert nicht, angeblich "Struktur zu komplex" MS Word 2002 auf Win2k: ohne Probleme. Auch ein Umkopieren der normal aussehenden Tabelle in ein neues Dokument bringt nichts. Das heißt also, man kann eine einmal vorgenommene vertikale Verschmelzung nie mehr ohne Nebenwirkungen rückgängig machen, wenn sie schon mehrere Schritte zurückliegt und ein "Undo" deshalb nicht möglich ist. Ist das so beabsichtigt? Ich halte das für einen Bug (auch wenn es in SO 5.2 auch schon so war). Hat jemand eine Ahnung, ob das in einer aktuellen M$-Word Version funktioniert? Meine alte WinWord 6 Version konnte noch keine vertikalen Verschmelzungen. wie oben beschrieben, mit der Word 2002-Version klappts ohne Probleme unter Windows 2000. Gruß, Guido Gruß, Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-dev] Fehler im csv Export in OO 2.0.x
Hallo Werner,
ich arbeite selbst oft mit CSV-Dateien, und zwar wie Du auch gemischt
deutsch- und englisch-formatiert. (Sowohl mit Microsoft Excel als auch
mit OOo Calc).
Gehe bei den Zahlen in Calc folgendermaßen vor:
Wenn Du eine CSV-Datei öffnen willst, kommt der Import-Filter. Wähle
hier zuerst die Trennart der Felder. Markiere anschließend das Feld mit
den Preisen. Vorgegebener Spaltentyp ist "Standard", den änderst Du
bitte in "US-englisch", und Calc ersetzt das englische
Dezimaltrennzeichen (der Punkt) mit dem in Deutschland üblichen
Trennzeichen (dem Komma).
Gruß,
Dennis
Werner Harrichhausen schrieb:
Am Samstag 14 Januar 2006 18:58 schrieben Stefan Weigel [ Stefan Weigel
<[EMAIL PROTECTED]> ] :
Hallo Stefan,
vielen Dank das du dir die Zeit genommen hast, die Dateien genau anzusehen.
Der Punkt ist, dass die von Dir verwendeten Konventionen für den
Aufbau der CSV-Datei ungeeignet sind, wenn Felder innerhalb der
Datensätze Zeilenumbrüche enthalten. Für solche Fälle gibt es die
Möglichkeit, die Felder zusätzlich durch Texttrennzeichen (zum
Beispiel " ) zu kapseln. Das ist ja auch per Default so vorgesehen.
Du verzichtest aber ausdrücklich darauf.
Du musst Dich entscheiden: Entweder Textrennzeichen verwenden oder
auf Zeilenumbrüche innerhalb der Zellen verzichten.
Nun die Entscheidung ist getroffen die Texttrennzeichen (") sind nun drin und
wurden korrekt verarbeitet.
Das unterschiedliche Verhalten von OO1.1x und OO 2 stifteten Verwirrung.
Ich habe aber noch eine andere Frage:
Bei den nun geänderten Formatierungen, aber auch schon zuvor (falschen
Formatierungen), werden die Zahlen in der Price Spalte teilweise falsch
interpretiert. Im Texteditor ist alles OK. Bei einem Öffnen der csv in OO 2
erscheinen teils die richtigen Zahlen, teilweise werden sie als Datum
interpretiert. Versuche ich diese Datumswerte in Zahlen umzuwandeln ergeben
diese einen ganz anderen Wert als den, der ursprünglich in der Zelle
gestanden hat. Die Ursprungs-Formatierung der Price Spalte war, Zahlen
(Standard).
Wie gesagt, die Datei wird korrekt verarbeit unter Froogle und auch im Editor
ist alles OK.
Weißt du woran das liegt?
Schönen Gruss
Werner
