ah.. found it

It is not related with the Merge

It is the problem of "some kind of MS Word vertical arrangement", I guess..

It is a TABLE, the height of CELL has restriced with unknown reason.

Just let it go, then you will be happy again

Bye..

Jerzy Czopik said:

Any CAT tool MUST retain the source formatting, otherwise it will be useless.

I agree... and as you can see the content perfectly well in the source we must be able to do this in the target too.  This means not taking the approach we do today (in my opinion) as we simply add text into a row where it won't fit.

So it's perhaps not so much of a bug, but rather a problem with the way in which we have resolved this issue of not being able to merge across paragraph breaks.  It might even be something that we cannot avoid with the current capabilities, but let's see what the development team have to say about this first as the change may not be trivial to achieve this.  If this is the case it probably won't get fixed at all since this is (as you mentioned earlier) a rather rare occurrence and definitely avoidable by preparing files for translation properly.

Evzen Polenka said:

Sure... from people which don't have the faintest idea about why it's 'not possible'... from people who don't understand that PDF is NOT just another document format... from people who hardly have an idea about the technicalities behind.

I believe that "one of the most requested features" from, let's say, often traveling salesmen is a teleport ;-)... but still no transportation company does not do any research or implementation in this regard...
...simply because someone sensibly evaluated the request and found it unreal or not worth the trouble...

You did make me laugh... but hardly the same thing.  At the end of the day people receive PDF files for translation and they just want a better way of handling them.  A perfectly reasonable request given the source of their income is coming from people who definitely don't have a clue.

Unknown said:

Woo..

You wrote "448 words" and I have failed to find Your solution for this problem.

Did I miss something ?

Yes.  There isn't one!  At least not without correcting the source file first.

no

you'd better do not touch the source

and most of the time, it is NOT allowed

Unknown said:

no

you'd better do not touch the source

and most of the time, it is NOT allowed

In this case of course it is.  The whole problem comes from converting the original source, a PDF in a really poor way.  If you read the rest of my post you surely see the problem?

You didn't notice that the source is a Word file converted from PDF... which is a source not only allowed to touch, but actually required to touch.

so, what you have said is just one line.

"I will talk to tech part and wait/see" Right ?

Paul Filkin said:

If you read the rest of my post you surely see the problem?

no there are no problem at all.

and

there are no solution at all too.

Yeah, the example was a bit extreme ;-)

I just disagree here...nonsensical requests are still nonsensical, no matter if they are made by people paying me.

"A better way of handling PDF" was known for ages - get the source format from which the PDF was created. Period.
And only if there is really really REALLY REALLY no chance to get the source, use the convert-to-word workaround, clearly understanding that it's just an emergency workaround with lot of drawbacks, not an easy-peasy day-to-day process.

That should be the message from big localization players towards the clients... because they don't believe poor translators, they believe only to big companies.

If the poor translators had their backs covered by such clear statements from big players, they would be able to argument with the ignorant clients... and won't be pushed to corner by "translate this PDF, or I'm going to ask someone else" requests.

EDIT::
Actually, getting back to the teleport example - I'm pretty sure that the salesmen most probably even DON'T request the teleport, simply because it's widely and publicly known that it's not possible.

It really doesn't help to look down on me and say "you have no idea about the technicalities". If I bought a BMW that gave conflicting readouts, I wouldn't expect to be sneered at by a BMW technician... Hopefully I would get it fixed. 

Nor would I expect or be interested in known "notorious" problems. 

Nor do I know for a fact that this came from a PDF... But from the way the lines are broken up it would appear blazingly obvious... Again, it's like taking the beamer back to the garage and them expecting you to tell them how the engine was originally constructed.

I'm a simple translator, trying to get a solution, that's all.  I've used pdfs and word countless times without problems.

And if I had a PDF or the doc file, without trados, I would be fine.

Which puts the ball back in the Trados court, since it either falsely shows merged and translated text in the editor view or falsely shows missing text in the preview. Blame whatever you want, but this problem continues unresolved.

And if I wasn't using Trados I wouldn't have this problem.

It really doesn't help to look down on me and say "you have no idea about the technicalities". If I bought a BMW that gave conflicting readouts, I wouldn't expect to be sneered at by a BMW technician... Hopefully I would get it fixed. 

Nor would I expect or be interested in known "notorious" problems. 

Nor do I know for a fact that this came from a PDF... But from the way the lines are broken up it would appear blazingly obvious... Again, it's like taking the beamer back to the garage and them expecting you to tell them how the engine was originally constructed.

I'm a simple translator, trying to get a solution, that's all.  I've used pdfs and word countless times without problems.

And if I had a PDF or the doc file, without trados, I would be fine.

Which puts the ball back in the Trados court, since it either falsely shows merged and translated text in the editor view or falsely shows missing text in the preview. Blame whatever you want, but this problem continues unresolved.

And if I wasn't using Trados I wouldn't have this problem.

If you'd buy a BMW with LHD, you will have a bit of trouble driving it in the UK. And if the car needs gasoline and you fill it up with diesel, it will end in a disaster. When you drive the car and it has a manual gearshift, you'll damage the engine, when you swicth the 2. gear while driving 200.

What you get from Studio are not conflicting readouts, but a file formatted as the source was. The problem here is, that you seem not to accept, that the software has its limits, which are no problem, if you know how it works. Same as with the car - it delivers what you expect, if used properly.

Robert Kingsmore said:

It really doesn't help to look down on me

I'm not looking down on you. I'm just stating the pure truth.
It may not sound pleasant, but that's not my fault. It's just a naked truth; it doesn't always sound good.

Robert Kingsmore said:

Nor do I know for a fact that this came from a PDF

Hmmm, how comes then that YOU mentioned that fact yourself:

John Kingsmore said:

As with many projects worldwide, a pdf was machine translated and the bilingual file sent to me for post-editing.

Robert Kingsmore said:

And if I had a PDF or the doc file, without trados, I would be fine.

But you DO have the DOC file! You can save it from Studio using Advanced Save... didn't you know that?

Robert Kingsmore said:

And if I wasn't using Trados I wouldn't have this problem.

You mean, if you would be typing in the Word file directly?
Then you would have exactly the same problem, just try it...

Or you mean, if you would use different CAT tool?
Then I truly believe that you would have exactly the same problem either, because the cause is the source Word.