I don't really want to post screenshots here of a proprietary solution. But here's a description of a similar FMP-based "publishing" solution:
You have a layout for end-users' main browsing. Similar-looking layouts are used for data entry, but include administrative functions, fields, and flags which expedite content creation, but are not meant for end-users. Typical FMP stuff. But now you take it to the next step:
You build a Report Layout specifically sized and formatted for printing and/or exporting to PDF. You use the FMP tools for object sliding; use Container Fields and/or WebViewer objects for illustrations; use the Merge Field function and/or text Calculation Fields to format text content from multiple data fields. You can overlap fields, so having a container field in the background is simple.
You basically ignore the "publish" Layout as you create, edit, and work with data. But it's always there, and is always "already built and populated." Whenever you want to publish a print version catalog for a particular product, you just launch an FMP script which automatically:
Prompts you for the desired set of records (product model, chapter, category, etc.)
Performs the necessary find and sort.
Creates a table of contents. (Based on another print-formatted Report Layout.)
Exports the TOC as a PDF. (Typically a dozen or so pages.)
Exports the content pages as a separate PDF. (Several hundred pages is no problem.)
In a few minutes, you have an updated print-ready book.
You open the Content PDF in Acroat Pro, insert the pages from the TOC PDF in the front of it, and send it to your on-demand printing outsource. The end result is a perfect-bound manual, without ever having jumped through hoops to dump data into a conventinal-wisdom page-layout app.
So this one FMP solution:
- Is used for data entry.
- Serves as a live internal reference tool served on FMPSA.
- Serves as a data export and data analysis tool.
- Can be bound as a fully-functional standalone runtime application.
- Is web-deliverable via FMPSA's IWP.
- Is web-deliverable as a web site's "backend data" via PHP.
- Serves as the "publishing platform" for print-ready and/or web-delivered PDF-based catalogs.
Vector drawings are created in Illustrator, Draw, CAD software, or whatever, and saved as vector PDFs in a folder acessible to the FMP database. The PDFs are named according to a record's unique identifier field (primary key).
You launch Acrobat Pro and run a Batch operation which opens the folder full of PDFs and batch-exports them to an adjacent PNGs folder. The PNGs are exported to the correct size for the Container Field(s) on the print Layout. (Optionally, another Container Field on the browsing Layout displays PDF icons which are links to the PDFs for when a user needs a scaleable, zoomable vector version.) During data entry, each time a new record is created or edited, a scripted button imports both the PNG and the PDF with a click; or batch-imports the images for all records at once.
One could just as easily build a layout and script the solution to create and send HTML-formatted emails of a found page or set of pages.
Like an XML / InDesign solution, FMP effectively figures out for you how many pages are needed for the length of the TOC, and the length of the parts list that accompanies each illustration and creates and numbers them; and it does so without any need for mucking around with XML.
So in this workflow, FileMaker Pro itself is serving as the "page layout" app. All that's sacrificed is high-end printing and exacting typography; which for many practical purposes today is becomming increasingly unnecssary.
The underlying concept herein is "FileMaker and PDF"; not "FileMaker and Illustrator." (Use any graphics program you want that can render to common RGB raster formats and/or PDF). And it's "let FileMaker automate the page assembly" instead of XML / InDesign. Just keep the page design within the capabilities of a FileMaker Layout.
JET
AdChoices