Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add author info onto PDF cover for normal maps #1677 #1722

Closed
wants to merge 1 commit into from

Conversation

eerohele
Copy link

@eerohele eerohele commented Aug 8, 2014

Fixtures.

I'm not sure the <xsl:template match="*[contains(@class, ' map/topicmeta ')][not(parent::opentopic:map)]"> template is actually 100% necessary, but I suppose it's a bit easier to add processing for <topicmeta> elements that aren't children of <map> if it's there since you can theoretically just do something like <xsl:apply-templates select="$whatever/*[contains(@class, ' map/topicmeta ')]"/> and have some kind of default processing.

@eerohele eerohele added feature New feature or request plugin/pdf Issue related to PDF plug-in labels Oct 27, 2015
@robander
Copy link
Member

robander commented May 3, 2016

Tested this change in 2.2.4 - it can add a lot more than the author onto covers. I created a couple of maps that use an excessive amount of metadata, including elements that have no general purpose at the map level, such as <linktext>. In a normal map, this change adds a lot of this material on the cover; in a bookmap, it adds less, but still more than I want. In both cases my cover gets navigation titles from child topics (this may be due to other changes in processing since the pull request was created).

I have created maps like this for testing in the past but couldn't find them; this time, I've posted them here for later reuse: https://github.com/robander/metadita/tree/master/sampledocs/metadata

@robander
Copy link
Member

robander commented May 4, 2016

One thought ... currently, the map/topicmeta match does nothing. This PR runs apply-templates on the content so that author falls through, but so does a lot more.

We could run apply-templates in the same location but with something like mode="topicmeta-front-cover", and the default rule for that mode does nothing. This would make it easier to customize to pick and choose what shows up (though I suppose it would make the order difficult - maybe apply with the mode on topicmeta itself). For 3.0, we can evaluate which of the many metadata options should show up on the default cover. I do like the idea that author shows up, for example.

@eerohele
Copy link
Author

eerohele commented May 4, 2016

Yes, this PR seems to need more attention for 2.2.4. I'll look into it when I get the chance. Thanks for testing it!

@jelovirt jelovirt added inactive won't fix This will not be worked on labels Oct 30, 2017
@jelovirt
Copy link
Member

Closing this as nothing has happened with this PR in a year. Because the only generic solution for the cover page is to output the title, outputting author info on the cover page should be a customization to the output.

@jelovirt jelovirt closed this Oct 30, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request inactive plugin/pdf Issue related to PDF plug-in won't fix This will not be worked on
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants