You might try exporting the file info metadata to a *.xmp file and editing that with a text editor, and then re-importing the modified *.xmp back into ID. Note that importing has options to replace or append. Windows Notepad can serve for editing, but I prefer Notepad++. I have used this to adjust custom metadata categories visible in stock InDesign only as raw data. In fact, I made a modest custom XMP panel for IDCS6 that lets me see (and fill in) custom categories, and have delayed moving to Creative Cloud because I’d have to figure out how to revise it for CC.
Good luck!
David

Acrobat Pro’s category of Image Object would appear to be limited to raster images: images formed from collections of vectors are something else, apparently undefined as far as Acrobat is concerned. For many versions, now right-clicking with Acrobat Pro’s Edit Object tool has been able to show the metadata for individual raster images, while vector images lack “object-level metadata” even though the vector images are included as distinct “object streams” within the PDF structure, the same category as raster images. Acrobat Pro’s Edit Object can select individual vectors, and with shift-click can collect several, but vector images seems to lose their original integrity.

For a while I have been using Adobe Illustrator CS6 to apply various categories of metadata, including Title and Description, to charts and diagrams before inserting them in ID, hoping that when PDF 2.0 arrives it will allow object-level metadata for vector images. A while ago I stumbled upon the “-ee” parameter for Phil Harvey’s wonderful ExifTool, allowing display of metadata in embedded objects. Lo and behold, sample PDFs yielded the Title and Description embedded in the AI artwork. Clearly, ID has been passing the information along. Perhaps Acrobat Pro simply disaggregates vector objects; hopefully other professional tools (from Callas, Enfocus, iText. others?) handle this better.

As for PDF 2.0, over on InDesign’s Acrobat forum, Dov Isaacs suggested on October 7th that PDF 2.0 support will not become mainstream before the second half of 2020:

https://community.adobe.com/t5/Acrobat/Acrobat-Pro-DC-create-PDF-2-0/td-p/10654727

David

I specialize in setting type for scholarly works requiring CJK characters, where the text is mostly alphabetic with occasional strings of mostly Chinese characters, especially in references. Over the years I’ve written a bunch of GREP queries for InDesign to do things like check strings of chars. lest they begin or end with a letter or digit — in other words, to add an ASCII space — or to pull spaces from within a C or J string. My basic building block is to GREP search for codes, usually with [\x{2E80}-\x{9FBB}]+. That doesn’t get everything, but I know what it misses and I’m less sure of what the might be missed using InDesign’s metacharacter for searching Kanji, ~K (tilde CapK). There are some very useful tidbits in a piece David Blattner posted ten years ago https://indesignsecrets.com/search-for-foreign-language-characters-in-text.php, with the ~K mentioned in the comments.

If your “nothing around the title” holds true, you could GREP search for [\x{2E80}-\x{9FBB}]+ (or perhaps ~K+) and replace with \x{300A}$0\x{300B} (where 300A and 300B are the Unicode values for double Chinese guillemets — substitute as necessary), with the additions picking up the font characteristics of the Chinese string. For most Chinese fonts, each guillemet adds half-a-character-width of whitespace on the outer side. That is often excessive where the string starts, and can look even worse at the end if the closing guillemet is followed by punctuation or a footnote number left dangling. The Japanese fonts bundled with InDesign automatically collapse this extra space, which is fine for Japanese text but can look odd elsewhere. Adobe’s open-source Source Han fonts (Google calls their versions Noto) can also narrow the extra space (these have smarts about the assigned language/locale, but I have not checked whether this affects spacing around guillemets). Also, the guillemets look very different for Adobe Ming (i.e., traditional chars.) and Adobe Song (simplified): many of my jobs use both fonts, but I prefer Adobe Ming’s guillemets, and make them all consistent — and have a char. style on hand with negative tracking to collapse the extra space; on the other hand, Adobe Ming’s double-width period, comma, etc. recall early days, when one form had to work both vertically and horizontally, so now I generally swap in Adobe Song. All of which is a long way of say Chinese punctuation ain’t simple.

Good luck!
David

Many versions ago InDesign added the ability to annotate one or a few characters. You might or might not get this to work for your situation.

So-called ‘furigana’ are essential in CJK typesetting, but before CC versions the details were not available in the English-language interface. Adobe’s help file explains them here<https://helpx.adobe.com/indesign/using/formatting-cjk-characters.html#add_ruby_to_text, using the alternate name, Ruby Text. You may still need to jump through some hoops to see the relevant menus in English, so you might want to experiment with MS Word’s “Phonetic Guide” feature for a general idea of how this works. Adobe’s Help says the offset of the ruby text can accept a negative value, which may or may not allow you to move the annotation below the parent text (MS Word apparently allows only positive vallues). Switching direction between RTL and LTR is crucial for you but I don’t know where you can find out about this — ruby are seldom discussed on Adobe’s forums. MS Word limits the annotations to about 20 chars., another detail that could be important.

If you have some HTML experience you may already know that HTML5 can also handle ruby text. This is one of the more complex features added in HTML5 (and therefore ePub3), so you cannot assume it will work everywhere. Still, it might be worth checking out <https://www.w3.org/International/articles/ruby/markup.en.

I might experiment with single-line paragraphs, with alternating languages and directions, perhaps with tabs between words/phrases to tweak alignment. But that seems like a lot of hand-work.

Good Luck,
David

The actual number of simplified characters is relatively small, on the order of a couple thousand (more are being added up in the 2nd plane but very few CJK fonts go beyond CJK Extension B). In other words, fraction of character counts. Also, Unicode swallowed up both simp. and trad. long ago, so that ? and ?, for example have separate codepoints, and only a very few fonts connect the two as variants of essentially the same char. (Needless to say, this means proof-reading requires a whole new degree of concentration.)

For the chars. just mentioned, BabelMap reports that I have 23 fonts containing ?, including Source Han Serif TC, and all of them also contain the trad. version, ?.

David

I’ve been reading William Taubman’s <i>Gorbachev: His Life and Times</i> (Norton, 2017), a Christmas gift from my daughter. The author explains in the front-matter his use of multiple systems for romanizing Cyrillic, which I understand (in a past life I published a few scholarly articles based on Russian sources.) But whoever was in charge of production at Norton simply dropped the ball on hyphenation, and not just for romanized Russian: I’ve been startled by the number of recto pages ending in the middle of an English word, entirely avoidable with a setting in ID.

Elaborating up on Chris’s worst case, I might consider creating a character style for romanized terms, and set its language to none, effectively turning off hyphenation. That might work most of the time, though inevitably it would cause some poor spacing. For those instances I could pull the char. style and insert my own discretionary hyphens. Someday AI may be able to help, but for now you may need someone who knows Russian to check.

Good luck,
David

Tables might work if you can live with their limitations. Simplest would be a 2-column table for each chapter, with each verse getting a cell; I might add a third column to hold verse nos., and “hang” it in the margin. Tables let you align the text within cells as you choose — top, center, bottom — and then the table takes care of aligning the rows; you might want to set the table to prevent cells from breaking between pages. In my work, the chief problem with ID’s tables is that they are incompatible with footnotes, so if you could not treat them as end-notes (where stock ID offers no help anyway) then they would have to be faked.

Running parallel bi-lingual text columns on each page, or perhaps on facing pages, would allow full use of ID’s features, and perhaps a clever scripter could figure a way to automate aligning verses. However, I assume that the length of verses is pretty close in both the English and French translations, usually within a line or two. So I might try defining three different paragraph styles for verse, identical except that the second would add a blank line for space after, and the third adding two. Still handwork, but speeded up. Starting a new chapter in the middle of the page might be more difficult than with tables handling verse formatting, but you could still add verse nos. in the margin via an anchored text box that would move with the verse.

Good luck!

David