Created attachment 47469 [details]
result of exporting to PDF

In second cell the paragraph indent before text is -0.66". So the text is outside the cell boundary thus it is invisible. When the user prints the document, the displaced content of second cell appears in the first cell. I think it should not happen, (e.g. MS Word does not print it).

By the way, you also can make the text reappear in sample by increasing left cell border distance to 140pt.

Bug or feature?

For me that is a WRITER rendering problem, I can't see any reason why the test should disappear because it leaves the cell. But it seems I am the only one who thinks so, in all older OOo versions (I tested 1.1.4) the text in sample document also is invisible, same in exported .doc and MS WORD viewer and sample with WORD2010.

Calc is more tolerant, see my "Text position riddle" in "Bug 39990 - Formatted rotated text misbehaves. It does not always remain in the cell".

DRAW objects allow text outside the object.

DRAW Tables behave completely different, they always keep all text contents within the cell.

May be some more consistence would be good, WORD should not set the standard, but usability.

@Christoph:
Any ideas?

Thank you Rainer, phew, this is a tricky one, because:
* security is as important as usability (possible to hide information without knowing, may be highly unwanted)
* the default settings in LibO will not cause that issue
* the issue is valid for many items (graphic objects, text document borders, ...)

The quick solution: Don't hide content and, thus, show and print such items.

The real solution (may need further investigation):
* Editing/viewing: The object bounding borders should "cut off" the content (like it is done here). But, a small visual indicator (incl. e.g. tool tipp) should provide a hint that content may be hidden. This could be something like the small red triangle used in Calc if the content doesn't fit into the cell.
* Printing/PDF export: Do also "cut off" the content, but hide the visual indicators.

Commercial: Such issues could be partly resolved by using a Document Checker like http://wiki.services.openoffice.org/wiki/User_Experience/DocumentCheck

Question: May this be something to be discussed during an ODF hackfest or in the ODF TC?

Created attachment 50471 [details]
sample with examples, see Comment 3

(In reply to comment #4)
> Question: May this be something to be discussed during an ODF hackfest or in
> the ODF TC?

IMHO good idea!

reproducible with LO 4.0.2.2 (Win7 Home, 64bit)

(In reply to sasha.libreoffice from comment #0)
> Created attachment 47468 [details]
> document with table that prints incorrectly
> 
> I found doc document that when printed, appears with some extra characters
> in one table. I have copy-pasted this table in new document and deleted
> unuseful content.
> To reproduce this problem:
> 0. Open odt file from attachment.
> 1. Export it as PDF
> In table appears some characters.
> This reproduced on LibO 3.4 rc 1 and LibO 3.3.2 on Mandriva 64 bit and
> Windows XP 32 bit

Reproduced.

Win 7 Pro 64-bit Version: 5.0.0.0.alpha1+ (x64)
Build ID: f3375fa07f27bd2ade519af3c07d69040d10eaa9
TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-22_23:38:50
Locale: fi_FI

Repro in 6.1+.

Same issue would also happen when the text is placed 20cm to left or right - and then you cannot just show it. So in contrast to comment 3 I wouldn't treat this as a rendering issue. Perhaps it's a question of the PDF filter that could hide/ignore objects not shown for some reason.

In the end users can mess up with formatting in several ways and we cannot take care of all. Security by formatting is definitely a bad idea. So my take is WF.

We discussed this issue in the design meeting. The use case might be to hide parts of the document by negative indentation, so it's a valid issue. Exporting the document with MS Word results in hidden text, just WYSIWYG. Maybe we do not respect the table cell transparency on export- that should be solved.

Another problem is the fact that there is no indicator for content outside the actual area. That goes into another ticket.

Dear sasha.libreoffice,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug