Formatting during text import

[000]

13 hours ago, Lagarto said:

There might be a bug in Publisher as it currenly does NOT remove the tag even if the Replace field is left empty, if the replacement contains a style criterion

I do believe this is on purpose — just imagine you want to replace the format of all paragraphs starting with "Hello" and Publisher accidentally deletes all the Hellos ... in an earlier discussion, I suggested a special character or code that will delete the found text (=tag), so that the user CAN delete it during can-replace but must do it on purpose.

I have just done a 48page catalogue with find-replace and it worked fine — while proper tagged import and plugins would be swell, for starters, I would be happy with a simple recording/macro feature so that I can save my find-replace commands and just call them up for the next publication.

By the way: I use TextSoap for my cleaning and sometimes, late at night, dream of the good old Corel Database Publisher — best importer I have ever useed!

[lacerto]

(...)

[lacerto]

(...)

[Matt Minde]

HI all! I realize everyone here wants the ability of AP to import tagged text of some sort.

I am a co-owner and production designer at a small independent newspaper in Yellow Springs, OH.

I have done a lot of work here using InDesign's (clunky) tagged text to generate and export copy from a FileMaker Pro database. Anything that changes periodically with repetitive but consistent formatting is ideal for this kind of process, e.g., telephone directory (yes, we produce our hometown phone book!), directory of businesses and organizations, classified ads, etc. I gleaned the coding from exporting as tags. Then when I generate copy from the database export, I save it as a .txt file and splice a header onto the top (that defines all the styles and parameters). I then import that text file into a blank InDesign document. (I do miss QuarkXPress for the ease of use of its XPress Tags.)

Tagging — or even style sheet matching — in a dedicated writing program like Word or Libre Office would be an ideal way to place writers' copy onto the layout page. Ever since the pandemic, we've been using Google Docs, which download as .docx files and retain formatting and style sheets. 

It would be a godsend to have such import functionality in AD: to simply be able to define a paragraph or character style, call it out in the .txt file, and import. Without this kind of functionality in AD, I simply cannot use it in our production environment. 

[MikeA]

7 hours ago, Matt Minde said:

It would be a godsend to have such import functionality in AD

Hear, hear.

My first exposure to QuarkXPress was at a DTP shop (anyone remember desktop publishing? : ). The people there weren't at all into tagging or command-line "stuff." I was, and when I learned about XPress Tags I dove into them and became good at devising scripts that would insert them with as much automation as possible into plain text. This provided a major boost in productivity for long-document jobs. At the time that approach seemed to be pretty uncommon (understandable...it's pretty nerdy stuff). I'd done something (vaguely) similar with translation tables and Compugraphic typesetting equipment—that was when I learned how a tagging system for formatting during text import could be an industrial-strength godsend. I do hope Publisher will have the feature some day. I suspect it would involve a lot of coding and a lot of design. How should the tagging for such a system look? Not just for "hard" formatting; how should tagging for styles look? (Please, not XSLT. Pretty please. : )

[Old Bruce]

I use Publisher's find and replace to find each tag and replace it with nothing but the Text style. Works for Character and Paragraph styles. Note that you may have to use the Regular Expressions for replacing the Character Styles.

[MikeW]

2 hours ago, Old Bruce said:

I use Publisher's find and replace to find each tag and replace it with nothing but the Text style. Works for Character and Paragraph styles. Note that you may have to use the Regular Expressions for replacing the Character Styles.

That's doable for simple tagged text use. But tagged text can/does include more than simple p.styles/c.styles use.

Six or so years ago, I guided a company's use for creating their catalog. Everything was held in a database. So using that database, their covers are created as well as the sections of the interior. Once the tagged text was imported, there was little work to be done manually. At the time, I created a mock-up to demonstrate the concepts. Here's the mock-up cover:

As well, tagged text can include things that cannot be directly done with simple formatting, like index creation:

<v14.32><e9>
@Index Heading:A
@Index Body:Abc Counseling And Family<\n>Services Inc    <A(3,"INDD",)[0]>25<A(3,"IND$",\#000\#027)[27]>
@Index Body:Abc Counseling And Family<\n>Services Springfield    <A(3,"INDD",)[0]>25<A(3,"IND$",\#000\#027)[27]>

All from out of the database. The snippet is part of an 500+ page medical services guide with 8 or so sections. All the sections are in the final tagged text file, which also applies the appropriate master pages for each section. It takes about 5 minutes for the entire publication to be created and is at least 99% finished when done.

I use tagged text for non-public facing hospital signage that merges various text, graphs and images. The typical 5 different posters take a few minutes to produce at an average of $300 per poster, 6 times a year.

[Old Bruce]

I would love for Publisher to use some form of tagged text Import (and Export as an xml file) Until that day...

[zixdesign]

ICML is only exceptionally wordy when you need to be able to create new content. For changing existing content in existing stories it isn't that bad. We have used a script that  isolates the actual text content from the tags for... well, about as long as ICML has existed. Yes, the InCopy markup language is very wordy indeed, but it can be made more usable.
For Publisher, the way to go would be to use their own equivalent to ICML (PCML? just a suggestion), and maybe to create a tagged format from that. I don't think using Adobe's markup languages with Publisher would be a good thing in the long run - unless Affinity haven't actually copied the entire text motor from Adobe. Which sounds unlikely.

[PaoloT]

On 10/20/2022 at 2:58 PM, zixdesign said:

For Publisher, the way to go would be to use their own equivalent to ICML

I fear a proliferation of "standards", none of them really standard. ICML has the advantage of being compatible with existing software used by a multitude of users.

If it can't be an Adobe standard, at least (or even better) it could be some other existing one. HTML5 looks like a good choice to me. Not compatibile with InDesign, but compatible with a lot of other things.

Paolo

 

[zixdesign]

HTML5? Well, that might be nice, but while it has some text features that many page design apps has lacked and may still be lacking, I think it might be too limited for page design. CSS3 is very nice but there is also things like master pages, anchored objects, conditional text... unless this is precisely what Publisher is already using - or some extension of it - I would feel doubtful. HTML5 extended (albeit a contradiction in itself) with CSS 3 extended perhaps...

[PaoloT]

6 hours ago, zixdesign said:

HTML5 extended (albeit a contradiction in itself) with CSS 3 extended perhaps...

Yep, I was thinking to the way styles and layouts are described in HTML+CSS bundles, like it happens in the ePub file format. In that case, you have the same code being able to describe both digital books and web pages. Since XML is extensible, I wonder if it can also be used to include description for printed page elements, including master pages.

This might be a standard created by Serif, based on an existing standard, and easy to adopt by other companies. Thinking to an analogy, the ePub file format itself has its root in a small ereader pioneering company named SoftBook Press. It has now became the standard file format for ebooks.

Aa another analogy: the SMuFL music font mapping was created by Steinberg, then not yet owning a music notation program (they were still developing Dorico). It is now the standard definition for music font mapping.

It would be nothing totally new (it will be based on universally used standards), but with that set of additional features that would make it the fast way to a universal page description standard.

I suspect CAT tools would be immediately compatible with this new interchange file format, if they already support HTML5 and/or XTML.

Paolo