Created attachment 61306 [details]
Source "justify" file

Created attachment 61307 [details]
Exported "justify" file

Created attachment 61308 [details]
Source "right" file

Created attachment 61309 [details]
Exported "right" file

Created attachment 61310 [details]
Justify.pdf in LO

Created attachment 61311 [details]
Justify.pdf in evince

Confirmed with:
LO 3.6.3.1 
Build ID: f8fce0b
Windows 7 Professional SP1 64 bit

Also Draw is importing some words in a sentence as a separate objects - see 8th sentence in attachment 61307 [details].

Marking as NEW as bfoman has confirmed.

Priotizing:

Minor: Makes creating professional quality work harder under specific situation and/or makes user not use certain features.

Low: Importing pdf's are uncommon in general, not many people affected, only happens when justify is set.

Reproduced.

Win 7 Pro 64-bit Version: 4.5.0.0.alpha0+
Build ID: 784d069cc1d9f1d6e6a4e543a278376ab483d1eb
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-01-25_23:07:36

Still reproducible.

Version: 6.2.0.0.alpha0+ (x64)
Build ID: 18c5089df091bddeb8c2dc339776671964389040
CPU threads: 8; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-09-12_23:24:12
Locale: de-AT (de_AT); Calc: CL

'Justify pdf' attached to this bug and newly created pdf are imported without justified paragraphs.

A newly created 'Right pdf' from source file attached to this bug is also wrong imported with spacing before text (which means on the right of the text).

Confirmed.
Version: 6.1.5.2
Build ID: 90f8dcf33c87b3705e78202e3df5142b201bd805
CPU threads: 6; OS: Linux 5.0; UI render: default; VCL: gtk2; 
Locale: ru-RU (ru_RU.utf8); Calc: group threaded

Mode "justify" isn't simply ignored. Sometimes lines of text became longer and exceed right margin.

Created attachment 150933 [details]
Source justify file (odt)

Created attachment 150934 [details]
Exported justify file (pdf)

Created attachment 150935 [details]
Exported file in Okular

Created attachment 150936 [details]
Screenshot of exported file, opened in LO

(In reply to Joel Madero from comment #8)
> Marking as NEW as bfoman has confirmed.
> 
> Priotizing:
> 
> Minor: Makes creating professional quality work harder under specific
> situation and/or makes user not use certain features.
> 
> Low: Importing pdf's are uncommon in general, not many people affected, only
> happens when justify is set.

I don't agree. Sometimes it's need to change some words in pdf file with many pages. And after that I have to check all pages and manually correct all lines that exceed right margin. I don't say about "professional quality work". I simply say about readable document.

*** Bug 47730 has been marked as a duplicate of this bug. ***

*** Bug 151554 has been marked as a duplicate of this bug. ***

*** Bug 151552 has been marked as a duplicate of this bug. ***

PDF does not have paragraphs or lines let alone justification options. Text in PDF is just a stream of absolutely positioned glyphs, it can come in any order and formation as long as it gives the desired visual output. Short of using the exact font with the exact glyphs and positioning every glyph individually to match the PDF positioning (which essentially means putting each glyph in its own text box, which I don’t think people will be thrilled about), I don’t see LibreOffice ever being able to exactly replicate the PDF text spacing.

> I don’t see LibreOffice ever being able to exactly replicate the PDF text spacing.

This does not mean that LibreOffice should distort the PDF document. There is an example of successful work with a formatted PDF document. Master PDF Editor does a great job with this task.

(In reply to خالد حسني from comment #25)
> PDF does not have paragraphs or lines let alone justification options. Text
> in PDF is just a stream of absolutely positioned glyphs, it can come in any
> order and formation as long as it gives the desired visual output.

While that is true in one sense, in another sense, it's false: When we look at a PDF, we see paragraphs and justification. So they are there, they're just not expressed explicitly.

> I don’t see LibreOffice ever being able to exactly replicate the PDF
> text spacing.

This bug is not about replicating the positioning exactly. It is about deciding which alignment the text in a line (or a paragraph, if/when we reconstitute paragraphs) has. We currently just choose "Left". Not "Right", not "Justified", not "Centered". It is quite doable to make a much better, and usually-correct, choice. To do so we need to:

1. Guesstimate where the text boundaries are for the page or part-of-the-page.
2. Determine how much extra space the paragraph has to its left and to its right.
3. Estimate whether the line is a list line on its paragraph
4. Try to decide whether the spacing of the words on the line is the result of adding extra inter-word space (justification) or not. Also determine the inter-glyph spacing and perhaps the glyph stretch factor (which can immediately be set for the text in the paragraph/line, if it's uniform at least.)
5. Try to decide whether the paragraph in its entirety is indented and/or has a first-line indent
6. Based on our determinations and guesstimates, set the indentation, alignment, and inter-word spacing for the paragraph.

... and that would typically come after deciding what the paragraph boundaries are; although some of it may need to be combined (e.g. distinguishing paragraphs by indents when there is no inter-paragraph spacing.)

And I'll emphasize again that this may not always result in the correct reconstitution of paragraph alignment - but it will certainly be correct for typical cases (think: the formal letter you exported as a PDF), and correct for the large majority of cases.


---------------------------------

> Short of
> using the exact font with the exact glyphs and positioning every glyph
> individually to match the PDF positioning (which essentially means putting
> each glyph in its own text box, which I don’t think people will be thrilled
> about), 

That's outside the scope of this bug. However, that's not what it means. You can very well set the spacing and stretch factors of individual glyphs within the same text box or on the same paragraph. And - that should definitely be an option when editing a PDF: Sometimes, what the user would want is a document that's easy to read, unladen with a zillion formatting and positioning specifications; but sometimes, what the user wants is a perfect reproduction of what the PDF looks like, to the extent LO is capable of doing so. The second case is for when one wants to make an edit to a PDF in LO (e.g. adding some text or a signature), and save the result - passing through LO should cause minimal distortion to the rendering of existing PDF content.

(Also, in the Writer filter, we typically don't want textboxes anyway, and the text should just go in the body.)

(In reply to Eugene Saenko from comment #26)
> > I don’t see LibreOffice ever being able to exactly replicate the PDF text spacing.
> 
> This does not mean that LibreOffice should distort the PDF document. There
> is an example of successful work with a formatted PDF document. Master PDF
> Editor does a great job with this task.

Master PDF Editor is a PDF editor, it does not import PDF into another reprentation to edit it, it works on the PDF structure directly. This gives limited editability options but it keeps the file structure intact. If this is what you need, please use it, LibreOffice PDF import can’t achieve this.

(In reply to خالد حسني from comment #28)

I agree with Khaled in the sense that LO is not supposed to maintain a PDF's internal structure (and hence is unlikely to preserve PDFs perfectly). But this is not a dichotomy. There is a spectrum between maintaining nothing, complete preservation like a proper PDF editor.

We can, and should, try to preserve - indirectly, via ODF-expressible features and structures - much of what the PDF contains. We can reach a situation in which most people would not notice significant (or any) distortions when opening a PDF originating in an exported word-processor document, or of a similar source.

This request would likely be better changed to "improve text block and its alignment recognition" task (if it's not filed already somewhere). In its current wording (and in its original description), it is simply wrong, implying that there is some metadata in the PDF that is ignored by LibreOffice; while the real task is inventing some heuristics to recreate such metadata from fixed positioning of glyphs on the media. It is related to e.g. "Consolidate Text" convenience tool introduced in 6.4 for tdf#118370.

Note that this comes up in bug 153888:  There's a simple(ish) PDF with some centered text in/over a gray frame. And - LO Draw doesn't lay out that text as centered at the horizontal center of the frame, nor is it designated as centered.

(In reply to Mike Kaganski from comment #30)
> In its current wording (and in its original description), it is simply wrong,
> implying that there is some metadata in the PDF that is ignored by
> LibreOffice;

Rephrased title to clarify this point.

*** Bug 149216 has been marked as a duplicate of this bug. ***

*** Bug 158173 has been marked as a duplicate of this bug. ***