For the PDF/lulu project, I actually did the cover layout in FM (11.778×8.75in overall).
The annoying thing about it is that the spine width, and thus total width, element locations, and maximum spine font size, vary with book page count, so it's impossible to provide a single covers.fm file that needs no further customization.
You'd ideally provide an app/script that generates the template, FM page size & PDF joboptions. As it was, it took a spreadsheet to manage all the dimensions, as the page count dithered around nearing pub date.
Today's authors, of course, just want to author their content, have the pub workflows happen automagically to HTML, eBook & PDF … plus of course print as an afterthought. This is years away.
PDF, eBook and HTML book editions typically need covers, but these are the same size as the interior pages, so just different Master Pages at most. Their content can be the authoring content source, and serve as Text Inset exports to the print cover layout (which is what I do).
Doing print covers is a pain no matter how done, due to the publisher-to-publisher specs, and the spine width being page-count dependent. A template kit would really need to include access to a web app to generate numerous iterations of several types of templates.
If full-bleed wrap-around art is needed, the thing really needs to be done in an art app: Photoshop, Illustrator, InDesign, etc.
But even for a plain white cover, that just needs text and maybe an icon on the spine, it's troublesome in FM, due to the spine's rotated text frame. Do the spine elements (TITLE, Edition, Author, icon) as a Table, and it gets even harder, because working with a tables in a rotated appears nearly impossible - and FM has no real concept of vertical centering for text … plus the max point sizes keep changing with the page count. The actual spine text probably needs to be drawn from a Reference Page or Variables so it can at least be typed in & revised.
Dust cover layout too? Yikes.
AdChoices