![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
Hallo zusammen,
in der neuen Version 3.4.0 tritt bei mir (WinXP) folgender Fehler auf:
Für die Unterteilung einzelner Abschnitte benutze ich die Umrandungs-Funktion (Linie am unteren Rand).
Auf dem Bildschirm ist alles richtig, beim Drucken fehlen aber diese Linien, bzw. es werden dicke Balken und senkrecht stehende Linien gedruckt.
Exportiere ich das Dokument als pdf-File, geschieht das koorekt und ich kann dann die pdf-Datei fehlerfrei drucken.
Es grüßt
Karl-Heinrich
Hallo,
Dieser Fehler tritt auch bei Win 7 auf. Ich habe in der Kopfleiste eine Linie eingefügt, welche über die gesamte Seitenbreite läuft. Bei der Ansicht stimmt alles aber beim Druck, ist die Linie dreifach so dick und im oberen Drittel der Blattmitte angeordnet.
Am Drucker kann es nicht Liegen, alles andere wird richtig auf das Blatt gedruckt.
Gruss
Peter
Hallo, Karl-Heinrich!
in der neuen Version 3.4.0 tritt bei mir (WinXP) folgender Fehler
auf: Für die Unterteilung einzelner Abschnitte benutze ich die
Umrandungs-Funktion (Linie am unteren Rand). Auf dem Bildschirm ist
alles richtig, beim Drucken fehlen aber diese Linien, bzw. es werden
dicke Balken und senkrecht stehende Linien gedruckt. Exportiere ich
das Dokument als pdf-File, geschieht das koorekt und ich kann dann
die pdf-Datei fehlerfrei drucken.
Hast du Bilder in dem Dokument eingefügt? Ralf Engelhardt und ich haben
nämlich ein ähnliches Problem, das immer auftritt, wenn Bilder mit im
Spiel sind. Siehe folgende Threats aus der [de-discuss]-ML:
[1] http://www.mail-archive.com/discuss@de.libreoffice.org/msg05537.html
[2] http://www.mail-archive.com/discuss@de.libreoffice.org/msg05600.html
[3] http://www.mail-archive.com/discuss@de.libreoffice.org/msg05673.html
Ob inzwischen ein Bug aufgegeben ist, weiß ich nicht.
Falls keine Bilder in dem Dokument enthalten sind, schicke mal eine
Beschreibung (am besten ausgehend von einem neuen Dokument der
Standardvorlage), nach der sich der Fehler reproduzieren lässt.
Gruß,
Christian.
Hallo Christian,
... Hast du Bilder in dem Dokument eingefügt? Ralf
Engelhardt und ich haben
nämlich ein ähnliches Problem, das immer auftritt,
wenn Bilder mit im
Spiel sind...
ja, so ist es tatsächlich:
Ohne Bilder werden die Linien (über Menü
Umrandung) richtig gedruckt, mit nur einem
Bild im Dokument liegen die Linien an völlig anderen Stellen und haben eine andere Dicke als vorher.
Der Umweg über ein pdf-Dokument geht zwar, ist aber natürlich umständlich.
Danke für den Hinweis
Karl-Heinrich
Da das ganz offensichtlich ein Fehler des Programms ist, solltest Du einen entsprechenden Fehlerbericht in Englisch verfassen, damit er gefixt werden kann.
Hallo Uwe,
ja, so ist es tatsächlich:
Ohne Bilder werden die Linien (über Menü
>Umrandung) richtig gedruckt, mit nur
einem Bild im Dokument liegen die Linien an
völlig anderen Stellen und haben eine andere
Dicke als vorher...Da das ganz offensichtlich ein Fehler des
Programms ist, solltest Du einen entsprechenden
Fehlerbericht in Englisch verfassen, damit er
gefixt werden kann.
mein Englisch ist leider sehr schlecht, sodass ich mich wahrscheinlich nicht klar ausdrücken kann.
Ich fände es deshalb gut, wenn jemand anderes diese Aufgabe übernehmen könnte...
Schon einmal vielen Dank vorweg
Karl-Heinrich
Hallo, Uwe!
Da das ganz offensichtlich ein Fehler des Programms ist, solltest Du
einen entsprechenden Fehlerbericht in Englisch verfassen, damit er
gefixt werden kann.
Habe ich getan:
https://bugs.freedesktop.org/show_bug.cgi?id=38041
Gruß,
Christian.
Im RC1 von LibreOffice 3.4.1 ist das Problem leider immer noch vorhanden. Vielleicht ist nicht klar, daß es sich dabei um ein gravierendes Problem handelt. Unser Büro arbeitet komplett mit OpenOffice. Eigentlich wäre jetzt eine Umstellung auf LibreOffice angesagt, aber unser Briefkopf enthält (wie sehr viele) eine Linie und eine Grafik. Seit LO 3.4.0 wird er wegen des Fehlers nur noch total vermatscht ausgedruckt. Das heißt LO ab 3.4.0 ist im kommerziellen Umfang praktisch nicht einzusetzen.
Natürlich könnte man jetzt auf die 3.3 umstellen. Aber wir lassen es vorerst bei OO, weil man sich natürlich schon fragt, wie es mit der Qualitätssicherung aussieht, wenn so ein gravierender Fehler durchrutscht und dann nicht einmal in der Folgeversion korrigiert wird, obwohl er bekannt ist.
Günter
Kannst Du mir das Dokument mal per PM schicken, damit ich ihn unter 3.3.3 testen kann?
Hallo Günter,
2011/6/23 Günter Urbanczyk schrieb:
Da das ganz offensichtlich ein Fehler des Programms ist, solltest Du
einen entsprechenden Fehlerbericht in Englisch verfassen, damit er
gefixt werden kann.Habe ich getan:
Richtiger Link:
https://bugs.freedesktop.org/show_bug.cgi?id=38041
Ist Duplicate zu
Bug 37488 - PRINTING result completely messed up
https://bugs.freedesktop.org/show_bug.cgi?id=37488
Im RC1 von LibreOffice 3.4.1 ist das Problem leider immer noch vorhanden.
Vielleicht ist nicht klar, daß es sich dabei um ein gravierendes Problem
handelt.
Das scheint klar zu sein:
Bug 37488
- ist ASSIGNED (Cédric Bosdonnat - 2011-06-06)
- hat Severity 'critical'
- Blocks: Bug 35673
Bug 35673 - LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673
Unser Büro arbeitet komplett mit OpenOffice. Eigentlich wäre jetzt
eine Umstellung auf LibreOffice angesagt, aber unser Briefkopf enthält (wie
sehr viele) eine Linie und eine Grafik. Seit LO 3.4.0 wird er wegen des
Fehlers nur noch total vermatscht ausgedruckt. Das heißt LO ab 3.4.0 ist im
kommerziellen Umfang praktisch nicht einzusetzen.
Natürlich könnte man jetzt auf die 3.3 umstellen. Aber wir lassen es vorerst
bei OO, weil man sich natürlich schon fragt, wie es mit der
Qualitätssicherung aussieht, wenn so ein gravierender Fehler durchrutscht
und dann nicht einmal in der Folgeversion korrigiert wird, obwohl er bekannt
ist.
Weiterführende Informationen:
Release Criteria
http://wiki.documentfoundation.org/Release_Criteria
Kriterien für ein Release
http://wiki.documentfoundation.org/Release_Criteria/de
Announcing a new beta release
by Italo Vignoli, 2011-05-13
http://blog.documentfoundation.org/2011/05/13/announcing-a-new-beta-release/
Release Plan
http://wiki.documentfoundation.org/ReleasePlan
Schönen Tag
Manfred
Im RC1 von LibreOffice 3.4.1 ist das Problem leider immer noch vorhanden. Vielleicht ist nicht klar, daß es sich dabei um ein gravierendes Problem handelt. Unser Büro arbeitet komplett mit OpenOffice. Eigentlich wäre jetzt eine Umstellung auf LibreOffice angesagt, aber unser Briefkopf enthält (wie sehr viele) eine Linie und eine Grafik. Seit LO 3.4.0 wird er wegen des Fehlers nur noch total vermatscht ausgedruckt. Das heißt LO ab 3.4.0 ist im kommerziellen Umfang praktisch nicht einzusetzen.
Natürlich könnte man jetzt auf die 3.3 umstellen. Aber wir lassen es vorerst bei OO, weil man sich natürlich schon fragt, wie es mit der Qualitätssicherung aussieht, wenn so ein gravierender Fehler durchrutscht und dann nicht einmal in der Folgeversion korrigiert wird, obwohl er bekannt ist.Günter
Die 3.4.1RC ist nur ein Kandidat für die Veröffentlichung. Keine fertige Version.
Vielleicht wird der Bug bis zur Veröffentlichung ja noch behoben.(Hoffentlich.)
Außerdem empfiehlt es sich immer noch eine weile zu warten, bevor man die neuste Version für den produktiven Einsatz Nutzt. Es ist nicht selten, dass auch bei Kommerzieller Software in der neusten "Hauptversion" noch gravierende Fehler auftreten , die erst nach ein oder mehreren Patches (siehe z.b. Win XP, Win Vista, Win7 , Internetexplorer,............) behoben werden. Bei Open source Software ist das leider nicht anders.(offt ist die fehlerbehebung bei Open source Software aber wesentlich schneller als bei kommerzieller Software. Vergleiche hierzu Sicherheitslücken bei Win7, die bis jetzt noch immer nicht behoben sind. )
Ich empfehle daher immer Versionen zu verwenden, die Ausdrücklich als "Stable" Gekennzeichnet sind, und wenn vorhanden LTS (Long term service) sind. (Das gilt auch für Linux, und andere Software)
Neuere Versionen sind eventuell für den Hausgebrauch, aber vor allem zum testen geeignet.
LiebreOffice hat angekündigt im Herbst eine Business-Version zu Veröffentlichen, die hoffentlich auch LTS sein wird.
Bis dahin empfehle ich für geschäftliche Zwecke LO3.3.3 zu verwenden , und auf die neuen Funktionen zu verzichten. (es sei denn es wird vorher noch eine andere Version ausdrücklich als Stabil gekennzeichnet, und die mailinglist ist nicht in den ersten Wochen nach der Veröffentlichung voll von Problemberichten.)
PS
Von OOo ist so schnell keine neue Version zu erwarten(und schon gar keine stabile) , da OOo gerade erst von Oracle zu Apache "verlegt" wurde.
Grüße
Frieder
Hi,
Bis dahin empfehle ich für geschäftliche Zwecke LO3.3.3 zu verwenden ,
und auf die neuen Funktionen zu verzichten. (es sei denn es wird vorher
noch eine andere Version ausdrücklich als Stabil gekennzeichnet, und die
mailinglist ist nicht in den ersten Wochen nach der Veröffentlichung
voll von Problemberichten.)
PS
Von OOo ist so schnell keine neue Version zu erwarten(und schon gar
keine stabile) , da OOo gerade erst von Oracle zu Apache "verlegt" wurde.
Oder doch eher OOo 3.3.
Da gibt es zumindest den für mich und viele andere ärgerlichen Bug (oder
Feature wegen Excel), daß in Calc Gitterlinien (nicht Umrandungen) nicht
angezeigt werden, wenn eine Hintergrundfarbe gewählt ist. Dadurch werden
solche Tabellen total unübersichtlich. Dies ist als EasyHack eingestuft:
'Let's make this an easy hack, so that an interested party can
contribute a patch for this.' Wie diese Aussage wohl zu bewerten ist?
Bin deshalb reumütig zu OOo zurück.
Gruß
Hi,
Bis dahin empfehle ich für geschäftliche Zwecke LO3.3.3 zu verwenden ,
und auf die neuen Funktionen zu verzichten. (es sei denn es wird vorher
noch eine andere Version ausdrücklich als Stabil gekennzeichnet, und die
mailinglist ist nicht in den ersten Wochen nach der Veröffentlichung
voll von Problemberichten.)
PS
Von OOo ist so schnell keine neue Version zu erwarten(und schon gar
keine stabile) , da OOo gerade erst von Oracle zu Apache "verlegt" wurde.Oder doch eher OOo 3.3.
Da gibt es zumindest den für mich und viele andere ärgerlichen Bug (oder
Feature wegen Excel), daß in Calc Gitterlinien (nicht Umrandungen) nicht
angezeigt werden, wenn eine Hintergrundfarbe gewählt ist.
Das kann aber auch Vorteile haben. Ich finde dass es besser aussieht, und wenn ich Gitter haben will, dann mach ich halt eine Umrandung(kann man auch in grau machen).
Wenn man etwas anordnen will, aber keine Gitter haben will, kann man einfach eine Hintergrundfarbe wählen (auch Weiß ) ohne die gitterlinein im ganzen Dokument auszublenden.
Ich denke, das ist nur eine Frage der Gewöhnung und des Geschmacks.
Dadurch werden
solche Tabellen total unübersichtlich.
Ein Gitter einzufügen ist nur ein Klick!!
Dies ist als EasyHack eingestuft:
'Let's make this an easy hack, so that an interested party can
contribute a patch for this.' Wie diese Aussage wohl zu bewerten ist?Bin deshalb reumütig zu OOo zurück.
Es will dich keiner hier gefangen halten. Ich bin auch gespannt, was Apache aus OOo macht. Und aus Testgründen (damit die Dokumente, die ich verteile auch auf beiden laufen) habe ich parallel OOo installiert.
LG Frieder
Hi,
Hi,
Dies ist als EasyHack eingestuft:
'Let's make this an easy hack, so that an interested party can
contribute a patch for this.' Wie diese Aussage wohl zu bewerten ist?
So wie es da steht ... die Lösung ist relativ einfach zu implementieren
und perfekt für jemanden geeignet, der in die LibO-Programmierung
einsteigen will. Ich hab's schon in nem anderen Thread (auf der
discuss-Liste) geschrieben: geschätzter Aufwand für jemanden, der sich
halbwegs mit C++ auskennt und ne lauffähige Buildumgebung hat: etwa ein
(voller Arbeits) Tag.
Mir wäre es lieber, es würde sich ein Student drauf stürzen, denn man
kann wirklich was bei lernen. Da das aber schon seit ein paar Wochen
nicht passiert, hab ich heute mal eine Mail an die design-Liste
geschickt, wie man denn am besten die Option umsetzen sollte. - Bisher
kein Feedback.
Drum jetzt hier nochmal die Bitte: wir brauchen eine *sinnvolle*
Abklärung, wo die Option hin soll. Und mit abklären meine ich hier nicht
zehn Leute, die ihre Meinung posten .. sondern ein oder zwei die sich
nen Kopf machen und dann eine konsensfähige Entscheidung treffen.
Mir ist nicht gerade langweilig, aber ich schau mir die nächsten Tage
mal an, wie man das implementieren kann. Wäre praktisch, dann zu wissen,
was denn konkret implementiert werden soll.
Gruß,
André
Hi,
Drum jetzt hier nochmal die Bitte: wir brauchen eine *sinnvolle*
Abklärung, wo die Option hin soll. Und mit abklären meine ich hier nicht
zehn Leute, die ihre Meinung posten .. sondern ein oder zwei die sich
nen Kopf machen und dann eine konsensfähige Entscheidung treffen.
Es gibt da, wie ich meine, einen guten Vorschlag:
https://bugs.freedesktop.org/show_bug.cgi?id=30800#c23
Gruß
Mit dem Drucken hast du natürlich recht. Ich benutze Calc hauptsächlich als großen Taschenrechner (Auswertung von Messprotokollen) und als Basis für kleine Hilfsprogramme, und nicht um aufwendig gestaltete Rechnungen oder Formulare zu drucken. Deswegen hab ich nicht so ans ausdrucken gedacht.
Aber wie ich eben gelesen habe will André Schnabel sich um das Problem kümmern. (Da sich sonst keiner darum kümmern möchte.)
Meine Kenntnisse in C++ sind leider nicht ausreichend um mich um eine solche Aufgabe zu kümmern.
Lg Frieder
Hi,
Hi,
Drum jetzt hier nochmal die Bitte: wir brauchen eine *sinnvolle*
Abklärung, wo die Option hin soll. Und mit abklären meine ich hier nicht
zehn Leute, die ihre Meinung posten .. sondern ein oder zwei die sich
nen Kopf machen und dann eine konsensfähige Entscheidung treffen.Es gibt da, wie ich meine, einen guten Vorschlag:
Lies doch bitte nochmal den Absatz, den ich oben geschrieben habe. Ich
finde es z.B. als Kompatibilitätsoption besser.
Also: bitte mal die Diskussion zum Design-Team tragen, ein paar Leute
fragen, die die Anwendersituation kennen (z.B. Trainer), einen Vorschlag
machen, der von mehreren getragen wird und diesen dokumentieren.
Hast du dir den Vorschlag schonmal durch den Kopf gehen lassen und
angeschaut, wie der im Endprodukt dann wirklich aussieht? Die
Optionsseite, auf der das drauf soll hat schlicht jetzt schon keinen
Platz mehr .. es passt einfach nicht drauf.
Das, was ich da im Bugtracker sehe ist die Meinung eines einzelnen
Anwenders. Ich bin auch ein Anwender und habe eine andere Meinung. Und
jetzt?
Gruß,
André
Hi,
Lies doch bitte nochmal den Absatz, den ich oben geschrieben habe. Ich
finde es z.B. als Kompatibilitätsoption besser.Also: bitte mal die Diskussion zum Design-Team tragen, ein paar Leute
fragen, die die Anwendersituation kennen (z.B. Trainer), einen Vorschlag
machen, der von mehreren getragen wird und diesen dokumentieren.Hast du dir den Vorschlag schonmal durch den Kopf gehen lassen und
angeschaut, wie der im Endprodukt dann wirklich aussieht? Die
Optionsseite, auf der das drauf soll hat schlicht jetzt schon keinen
Platz mehr .. es passt einfach nicht drauf.
Könnte man das Dialogfenster nicht vergrößern?
Da man hier die Gitterlinien beeinflussen kann, würde diese Option hier
gut hinpassen.
Das, was ich da im Bugtracker sehe ist die Meinung eines einzelnen
Anwenders.
Mit mir schon zwei.
Ich bin auch ein Anwender und habe eine andere Meinung. Und
jetzt?
Letztendlich ist mir das egal, wie es gelöst wird. Hauptsache es gibt
eine Option dies zu ändern.
Gruß