Pages in topic:   [1 2] >
Layout issues translating .svg files - any ideas?
Thread poster: Adrian Garcia-Landa

Adrian Garcia-Landa  Identity Verified
Germany
Local time: 21:49
English to French
+ ...
Apr 5

Hi,

I'm translating a book explaining economics with infographics from German to French.

Since the text is not entirely recognized during the IDML export (only 20%), I work with the .svg format. I export a PDF from indesign, import into illustrator and export it as a .svg. I translate that in my cat tool.

The result is not very good: the text are where they sould be, but they are bungled and messy. Have a look:
https://camembertcom.wordpress.com/2017/04/04/translating-indesign-files/

You clearly see the difference.

Obviously the tags in the SVG format are some kind of mapping instrument.

Is there another way than using the SVG format? Thanks for letting me know.

Best,
Adrian


Direct link Reply with quote
 

Mario Chavez  Identity Verified
Local time: 15:49
English to Spanish
+ ...
Wow, that's messy! Apr 5

Hello, Adrian,

I am a translator and a DTP typesetter as well, having worked with Illustrator and InDesign for many years. Since SVG is a vector image, it should show a text layer on Illustrator. Yes, the text may be extractable (after all, I'm suspecting your tool extracts the text layer) but the results are messy for a number of possible reasons:

a) The kerning is way off for that typeface
b) Your software (or your client's) to display the document is replacing the original typefaces with their own system typefaces
c) An InDesign document using SVG or other graphic files containing a text layer should have embedded typefaces

The above may serve as talking points with your client.

Let me know how it goes!



Direct link Reply with quote
 
Joakim Braun  Identity Verified
Sweden
Local time: 21:49
German to Swedish
+ ...
Bad workflow Apr 5

Frankly, what do you expect from a workflow like that?
If the customer wants useable layouts delivered, the translator must work in the original layout software. No ifs and buts.

Here, parts of the Indesign file could be linked graphics, and the text in those wouldn't be included in the IDML.
Linked graphics should be translated in the original graphics software (where layouts can be adjusted or text edited to fit the layout perfectly).

In the SVG export, line fragments seem to have been rendered as separate text elements. Since source and target text length differs, you get gaps. (In a properly exported SVG this would be less of a problem.)

You have three options: Use proper software (apparently you have Indesign, so no problem there), renegotiate your deliverables or refuse the job.


Direct link Reply with quote
 

Mario Chavez  Identity Verified
Local time: 15:49
English to Spanish
+ ...
Good point, Joakim Apr 5

I haven't directly worked with SVG files in Illustrator for an InDesign deliverable, so I was giving general advice.

From what you're saying, Joakim, SVG text manipulation is like that done on Crystal Reports: text is split in segments and the rendering is atrocious.

I agree: for InDesign, all graphics should be linked to the main document. Good practices recommend using .AI, .JPEG or even .PDF graphics instead of large graphics, such as EPS or SVG*.

*I understand that SVG files tend to be large.


Direct link Reply with quote
 
Joakim Braun  Identity Verified
Sweden
Local time: 21:49
German to Swedish
+ ...
Well Apr 5

SVG per se doesn't necessarily split text into line fragments - it has HTML-like text block capability.

But when exporting PDF from Indesign with linked vector files (where the idea of the PDF format is perfect and identical rendering everywhere), then opening that PDF in Illustrator and exporting as SVG - well, no text wrap mechanism would survive that.


Direct link Reply with quote
 

José Henrique Lamensdorf  Identity Verified
Brazil
Local time: 17:49
English to Portuguese
+ ...
Bad workflow Apr 5

The viable workflows I know are:

1. Traditional - directly on InDesign
You'll have to copy & paste each block of text to a file compatible with your CAT tool, get it translated, and then copy & paste back onto the right places on InDesign.
This process is still used when the DTP operator does not translate, or is unfamiliar with the target languages, especially when there are many of them.

2. Modern - still using InDesign
Some CAT tools are able to "trespass into" InDesign files to translate them.
Later someone - it may be the translator him/herself or not - will open the resulting files on InDesign, and fix the layout issues resulting from text swelling/shrinkage in translation.

The two methods above are required if the client demands translated files in InDesign format.

If a PDF is acceptable as translated output, there are more options.
These start with InDesign outputting the source file to a PDF

3. Infix
Infix exports all text to tagged XLIFF, XML, or TXT for translation, and tags the PDF as well.
Later Infix will import the tagged translation into the right places/formats, and it includes all the DTP tools necessary to fix layout issues on the PDF.

4. Other PDF editors with translation features (e.g. NitroPDF)
I never tried any of these, however I guess they allow to translate text directly on the PDF, and have the tools required to fix the layout. I have no idea on how - and if - they include CAT tools in the process.


Direct link Reply with quote
 
Miodrag Zizovic
Serbia
Local time: 21:49
English to Russian
+ ...
Everything should be done with InDesign Apr 5

Greetings,

I am DTP specialist with work experience of over 2 years now as a full time job. Your problem sounds like you have linked text as object in yours first InDesign document - it may be another PDF or image. So when you do export to IDML that linked text is not exported.

Way I would solve it:

Make PDF from INDD file. Than use that PDF in split screen with InDesign for marking - see in InDesign what texts are not editable and mark those parts in PDF (some parts in PDF can look like text that can be selected, but that text in ID can be presented from another PDF link so check ID for editable text). Than use marked PDF in some OCR tool - for me that would be Abbyy FineReader. Reconstruct non-editable parts in InDesign and export to IDML.

Avoid dealing with PDF directly - here is why:

- text that appears that can be selected from PDF may not represent same text that you see on screen! Some OCR tools like Adobe Acrobat built in OCR would do OCR recognition without user assistance and final result from that operation may seem like an editable PDF document, but in reality it may be full of spelling mistakes all over the place;

- lets say that you have perfect working PDF with all text inside editable and with correct formatting. Still dealing with text formatting inside PDF with tool such as Infix Pro/FoxIt/Nitro/Acrobat/Finereader 14 PDF editor etc. is very painful and many things can go wrong in translation! I would rather rebuild document in Word as last option and send it to translation than use direct PDF post-editing.

With kind regards, Miodrag.


Direct link Reply with quote
 

José Henrique Lamensdorf  Identity Verified
Brazil
Local time: 17:49
English to Portuguese
+ ...
I beg to differ Apr 6

Miodrag Zizovic wrote:

Everything should be done with InDesign

I am DTP specialist with work experience of over 2 years now as a full time job.


This is not a measuring contest, but I am a translator who has been doing DTP for 30 years with MultiScribe (Apple II & dot-matrix printer), PageMaker, and now Infix, as a final step for some of my translations. Been there, done that long and often enough to have a fairly encompassing view of what it takes.

Miodrag Zizovic wrote:

Avoid dealing with PDF directly.


This is where we we disagree.

You are a DTP specialist, IOW a creative graphic artist who puts content - words & imagery - into a visually appealing format.

Translators - supposedly most of the Prozians - replace those words with a different language, and sometimes are required to preserve/rebuild that visually appealing format, compromised by text swelling/shrinking in translation.

By concept, translators are NOT expected to create a new graphic design.

A translator doing everything in InDesign needs to buy a license, or work full-time in a company that has done so. AFAIK it's not at all cheap. A freelance translator who gets into DTP will have some InDesign requests, but also may have the same involving QuarkXpress and FrameMaker. Should s/he buy them too? A pretty hefty investment, since each of these three high-end apps uses its proprietary file formats, incompatible with the others.

And then there is the time investment in mastering each of them, and a freelance translator might also get requests using low-end DTP apps, like Microsoft Publisher, Serif PagePlus, and Scribus. MSPub is included in the Office suite, PagePlus is comparatively cheap, and Scribus is freeware. Yet each one has its independent learning curve.

Miodrag Zizovic wrote:

- text that appears that can be selected from PDF may not represent same text that you see on screen!


AMOF nothing you see in a PDF is actually what is there. I tend to equate a PDF file to a movie set. When you see a scene "in Manhattan" on the screen, experts will have done their best to leave the spectator in a quandary on whether it was actually shot in NYC, or if it's a stage with painted wood panels held together with tape and wire that looks exactly like that street. Nowadays it's just a chroma key background, where they'll add digital photographs later.

In short, a PDF file, if looked from the inside, no longer resembles the DTP file used to create it. Text blocks often look assembled like a ransom note, though they exist as plain text elsewhere in the files.

However the PDF was a final publication before translation, and the mission here is to make it look so afterwards. Since by concept the translator is NOT expected to create a new layout, a PDF editor should enable him/her to restore that look. This is all the DTP usually required - if and when it is so - from a translator.

My point is that - if the client will accept a translated PDF - buying one PDF editor and learning to master it would be a sensible investment for a freelance translator.

Miodrag Zizovic wrote:

Still dealing with text formatting inside PDF with tool such as Infix Pro/FoxIt/Nitro/Acrobat/Finereader 14 PDF editor etc. is very painful and many things can go wrong in translation! I would rather rebuild document in Word as last option and send it to translation than use direct PDF post-editing.


The question is: HOW painful?

MS Word is a word processor, its original paradigm is the typewriter. You can't start on page 60, then work on page 25, move to page 2, and then proceed on page 44 without messing up the whole thing.

It's like stuffing a sausage. If you've done it for about two yards, and then notice that a meat grinder bolt fell into it at about two feet from the start, you'll have to empty it back there to remove, or rip it open at that point.

When you change things in the middle of a Word file, everything beyond that gets displaced.

PageMaker and its son, InDesign use the ancient paste-up studio as a paradigm, including all the external vendors (typesetting, drawing, photo services) within. That's real DTP. AFAIK the other DTP apps have no real life paradigms, these were created inside a computer.

PDF editors - at least Infix - try to create that same paste-up studio environment, however with all the shortcomings of PDF files. It is not a street in NYC, but a stage, and you often have to re-conceal duct tape and wires that were not visible in the original, pre-translation publication. At least Infix has a host of tools to make that easier.

Editing a PDF is often painful, however it equates to a novocaine shot, if compared to doing DTP with MS Word, which in this analogy should correspond to surgery without anesthesia.

In a nutshell: Doing DTP with a word processor often involves unbearable pain.


Direct link Reply with quote
 

Mario Chavez  Identity Verified
Local time: 15:49
English to Spanish
+ ...
Measuring contest Apr 6

Apparently, there IS a measuring contest about who has more experience doing DTP or using InDesign.

Back to Adrian's conundrum: the consensus is that SVG, being vector graphics and containing text layers) should be edited into the target language first, then link them back to the InDesign file.

If the final product is expected to be an InDesign file, that means, to me, it is for publication, whether the client wants a preflight PDF or not.

Now, a source-language PDF will show, among other things, what fonts are embedded or used in the document, and what program was used to generate the PDF. Even if the client sends me an InDesign package (best practice) and a separate PDF in, say, English, I go to Acrobat>File>Properties to find out whether the PDF was actually created in InDesign.

Depending on what I find out, I can then ask the client for the missing typefaces (a typical problem, especially if the client created the PDF on a Mac using Mac-compatible InDesign. Reason? Some Mac fonts don't have a Windows equivalent, especially if you end up working with InDesign or Acrobat in Windows.

I would stay away from programs like InFix or NitroPDF, ABBYY Reader and other PDF-like programs, to avoid compatibility issues to begin with.

In the end, it is difficult to give you, Adrian, a specific, good advice on your case without taking a look at the files (the native files, what platform they were manipulated in, etc.). A graphic screenshot offers limited information.

Any of the experts here can help you out with the native files and diagnose the problem and how to solve it.


Direct link Reply with quote
 
Miodrag Zizovic
Serbia
Local time: 21:49
English to Russian
+ ...
No hard feelings Apr 6

Greetings everyone,

I made experience statement only to give you insight of my expertise. There is not contest involved.

I understand yours point of view, and if it methods you described work good for you than it is fine. However, buying CC licence for an active person in this business is real cheap deal. Still poster of question have spoken about exporting IDML, so he most probably do have active licence for ID.

Anyhow, using MS word over editing PDF directly has number of advantages in this case where 80% of text is not recognized by IDML export. There are number of ways to make .doc file for translation and by using frames and/or page breaks you can easily make layout that will not move text after quick edit / translation if that is troubling you, but with a bit of scaling/spacing/line spacing you should have no trouble in post translation process as long as you follow document and its layout from beginning to end. Specially this case is good for it, because DE is slightly longer language than FR. Anyhow it is point of personal preference - from my perspective Word method is far safer and easier assuming client wants PDF as target document format.

Off topic:
There is a lot of topics opened up now, but there is no point going in with discussion about them. For some points I agree for some disagree, but with respect to everyone in this conversation it is safe to say that method that works for user is the best way to go for.

I believe that we achieved purpose of this topic and that Adrian now have enough clues on how he can proceed from this point.

Thanks everyone and have my honest regards.


Direct link Reply with quote
 

José Henrique Lamensdorf  Identity Verified
Brazil
Local time: 17:49
English to Portuguese
+ ...
Some closure Apr 7

Actually there is no point in discussing how many years a translator has in DTP, but merely turning it onto a yes/no question. Most of the translators I know do NOT get into DTP, they are linguists. However, in order to either make a client happy, or merely to get a desirable translation assignment, many indulge in doing "DTP" using a word processor after translation. This can often be a painful process, and many of them do it for free. IMHO doing DTP with a word processor is about as easy and rational as subtitling video with PowerPoint.

Some translators try to do DTP, and realize that the learning curve may be quite steep. In spite of my extensive experience and mastery with PageMaker, I tried my hand with both QuarkXpress and FrameMaker. I quickly realized that I was back to square one, and gave up on them.

Having started on an Apple II, and later having moved to the PC, I went through a long series of word processors until powerful marketing made MS Word the one and only market standard. Such changes were somewhat like moving from one car brand/model to another, it's a matter of finding where are the controls to do the same thing.

In one car, you turn on the lights by pulling a button on the dashboard; in another you twist the turn-signal lever tip; in a third one you twist a button, and so on. In all of them, as the headlights are turned on, you can see the road ahead at night.

Not in DTP. Each program has a different concept. It's like moving from a wheelbarrow to a motorcycle, and then to a four-wheel vehicle.

Nowadays, all DTP files merge into PDF, like in the past they ended with a photolith for an offset printer.

In spite of their extreme flexibility, PDF files are internally complicated. Some major issues that may puzzle translators unfamiliar with anything beyond DOC/DOCX/RTF files are:

1. Partially embedded fonts - For file size saving reasons, PDF files usually contain only the characters actually used from a specific font. My pet example is the word "republican" (10 chars, none repeated - no political innuendo here). If this word, and nothing else, is found using a specific font in a PDF file, that file will only contain these 10 chars from this font. Upon translating it into, say, PT or ES = republicano, we will lack the letter "O". Either we have that font on our computer to add it there, or we must get it from the client (technically, a copyright infringement), or a license for it (which may cost anything from free to $300). Plan B is the client's permission to use an alternative lookalike font for the entire word.

2. Unexpected font variants - In word processors, the buttons for bold, italic, underscore, and sometimes outlined text are clustered together. A PDF is all about what it looks like.
Some fonts have their bold, italic and other variants as separate fonts, and the program will automatically shift between them.
When a font doesn't have a bold variant, some DTP programs will overlay the text twice, with a 1-pixel offset between layers to get the bold effect. The PDF contains that text twice.
When a font doesn't have an italic variant, some DTP programs will slant letters to create it.
However there is NO underscored font. Programs merely draw a line under the text. So a PDF file will most likely have the underscored text and a "loose" line under it. Of course, after translation that line will be off-place and off-size. Infix specifically devised a feature to spot underscored text and rebuild it as such, but it can't be 100% effective.
Some (rare) DTP apps render outline fonts by accurately overlapping a reversed smaller letter on each letter in the actual text. So the PDF has that text twice, and if one of the colors involved is white, one of them might be invisible.
Editing a PDF is often like unraveling a magician's trick.

3. Uncanny text structure - Again, a PDF is about how it looks like, with no regard to the actual document structure. A paragraph may have soft and line breaks everywhere, it may be split into irrational parts, there might loose words (though perfectly aligned, visually) in different layers, multiple spaces may abound where there should be only one, etc. Furthermore, character width, horizontal and vertical spacing, kerning, etc. will all look as "random" after a DTP file has been distilled into a PDF.
The point is in how a PDF is created, a two-step process. The DTP (or any other) app will print to a PostScript (a printer language) file, which merely "tells" the PostScript printer what should be where, regardless of whether it will make sense to a human or not. Then that PostScript file will be "distilled" (the name given by Adobe, which developed the format) into a PDF file, so any PDF reader will render it as if the computer were a "printer". However at this time, if a text block appears like a text block, it is possible that the reader software did some work to make it look so. If you change (i.e. translate) that block, this may thwart this function.

4. Ghosts - A PDF file is usually self-contained; it includes all elements in building it. To illustrate, both PageMaker and its son, InDesign, give the option to include, say, photographs, within the file, or merely leave them linked. The PDF, in order to be a single, complete file, must include them.
So I've seen it. A behemoth-sized PDF file had no reason to be so large. Why was it? Well, the small portrait of one individual had been masked from a group photo of some 30+ people, in extremely high resolution. Upon distilling the PDF, the entire photo was included in the file.
Some PDFs include layers and layers of deleted material which was not actually deleted, but merely covered with layers and layers of white strips. This may be how InDesign works to enable the Undo function when something is deleted.
Then there are always layer sequencing and transparency issues to struggle with.


This message is not intended to solve the OP question. My goal was to clarify some issues for translators who are thinking about getting into DTP... or not.

I still see three main pathways for translators:

A) Getting a DTP app and becoming proficient in using it. This is mandatory when the client demands the translation to be done on the DTP app, and viable when the translator's demand for such work justifies - financially - this investment.

B) Getting a PDF editor and mastering its use, wary of the pitfalls I mentioned above plus many others. The money investment is considerably lower (DTP editors cost a fraction of any pro-level DTP app), however the investment in time to tame the PDF quirks might be longer.

C) Creating a partnership with a DTP operator who uses either method (A) or (B), and jointly developing a suitable workflow.

I fail to see doing DTP work on a word processor as a viable option.


Direct link Reply with quote
 

Mario Chavez  Identity Verified
Local time: 15:49
English to Spanish
+ ...
Another path Apr 9

I see that there is another option for a translator to work with DTP: study graphic design and/or typography. Some foundations on information design and technical communication can be useful too.

One needs to know the principles for doing desktop publishing, regardless of the tool. The principles, such as contrast and balance, are constants, whether one uses InDesign, PageMaker, Illustrator or Quark Xpress.

For the very reason PDF files have complex internal mechanisms, I don't use them as editable material but as deliverables. That's how it is done with professional DTP.

I hope Adrian found a workable answer.


Direct link Reply with quote
 

José Henrique Lamensdorf  Identity Verified
Brazil
Local time: 17:49
English to Portuguese
+ ...
Translation vs. creative DTP Apr 9

Mario Chavez wrote:

I see that there is another option for a translator to work with DTP: study graphic design and/or typography. Some foundations on information design and technical communication can be useful too.

One needs to know the principles for doing desktop publishing, regardless of the tool. The principles, such as contrast and balance, are constants, whether one uses InDesign, PageMaker, Illustrator or Quark Xpress.

For the very reason PDF files have complex internal mechanisms, I don't use them as editable material but as deliverables. That's how it is done with professional DTP.


Of course, DTP is a career in itself beyond translation, however potentially associated.
The same would apply to learning web design.
If a translator takes any of these paths, s/he will be able to offer bilingual DTP, bilingual site development, which definitely means added value.
However this is a farther stretch than learning to translate one more language.
Also, it is different from a completely different professional endeavor, like carpentry, embroidering, photography, etc.

An important "grey area" between translation and DTP is "restoring the layout after translation". This does NOT involve learning graphic design, but merely learning to use DTP tools to format the translated text in order to make it look as much like the original as possible.


Direct link Reply with quote
 

Mario Chavez  Identity Verified
Local time: 15:49
English to Spanish
+ ...
I disagree - restoring layout Apr 9

José Henrique Lamensdorf wrote:

Mario Chavez wrote:

I see that there is another option for a translator to work with DTP: study graphic design and/or typography. Some foundations on information design and technical communication can be useful too.

One needs to know the principles for doing desktop publishing, regardless of the tool. The principles, such as contrast and balance, are constants, whether one uses InDesign, PageMaker, Illustrator or Quark Xpress.

For the very reason PDF files have complex internal mechanisms, I don't use them as editable material but as deliverables. That's how it is done with professional DTP.


Of course, DTP is a career in itself beyond translation, however potentially associated.
The same would apply to learning web design.
If a translator takes any of these paths, s/he will be able to offer bilingual DTP, bilingual site development, which definitely means added value.
However this is a farther stretch than learning to translate one more language.
Also, it is different from a completely different professional endeavor, like carpentry, embroidering, photography, etc.

An important "grey area" between translation and DTP is "restoring the layout after translation". This does NOT involve learning graphic design, but merely learning to use DTP tools to format the translated text in order to make it look as much like the original as possible.


I see no gray area between translation and DTP in terms of restoring the layout after translation. Without graphic design (and information design & technical communication) principles or basic knowledge, a translator, however proficient in a DTP program he or she is, will not know how to implement an appropriate target-language layout to the document.

Unlike math, chemistry and other exact sciences, document layout is not predicated upon universals: each language has a document, book or brochure layout tradition that has to be considered, accounted for and applied as best as possible.

Put it another way, no amount of knowledge about Photoshop will make you a better photographer.


Direct link Reply with quote
 

José Henrique Lamensdorf  Identity Verified
Brazil
Local time: 17:49
English to Portuguese
+ ...
We are speaking different "languages" Apr 9

Mario Chavez wrote:

José Henrique Lamensdorf wrote:

An important "gray area" between translation and DTP is "restoring the layout after translation". This does NOT involve learning graphic design, but merely learning to use DTP tools to format the translated text in order to make it look as much like the original as possible.


I see no gray area between translation and DTP in terms of restoring the layout after translation. Without graphic design (and information design & technical communication) principles or basic knowledge, a translator, however proficient in a DTP program he or she is, will not know how to implement an appropriate target-language layout to the document.

Unlike math, chemistry and other exact sciences, document layout is not predicated upon universals: each language has a document, book or brochure layout tradition that has to be considered, accounted for and applied as best as possible.

Put it another way, no amount of knowledge about Photoshop will make you a better photographer.


The gray area is in terms of the service offered. A customer wants their publication both translated AND looking like the original. This may involve one or two separate vendors.

If it's one, it is more likely to have a translator who can "dupe" text formatting (supposedly s/he won't fidget with illustrations) than a DTP operator who is capable of translating.

What I mean is that this translator, even if devoid of visually creative sill/talent, can adjust TEXT that was, say, in Helvetica 9pt over 12pt, into Arial 9 pt over 11.5pt, for it to cover exactly the same area, if the text has swollen a bit in translation, provided some software enables them to do it. No Michelangelo required here.


Direct link Reply with quote
 
Pages in topic:   [1 2] >


To report site rules violations or get help, contact a site moderator:

Moderator(s) of this forum
Laureana Pavon[Call to this topic]

You can also contact site staff by submitting a support request »

Layout issues translating .svg files - any ideas?

Advanced search






memoQ translator pro
Kilgray's memoQ is the world's fastest developing integrated localization & translation environment rendering you more productive and efficient.

With our advanced file filters, unlimited language and advanced file support, memoQ translator pro has been designed for translators and reviewers who work on their own, with other translators or in team-based translation projects.

More info »
WordFinder
The words you want Anywhere, Anytime

WordFinder is the market's fastest and easiest way of finding the right word, term, translation or synonym in one or more dictionaries. In our assortment you can choose among more than 120 dictionaries in 15 languages from leading publishers.

More info »



Forums
  • All of ProZ.com
  • Term search
  • Jobs
  • Forums
  • Multiple search