Bug #2688

embedded text format ignored by Metacat

Added by Inigo Gil almost 16 years ago. Updated about 14 years ago.

eml - general bugs
Target version:
Start date:
Due date:
% Done:


Estimated time:


When metacat displays metadata documents, the original format is often lost. Newlines, new paragraphs, bullets and the like are largely ignored by the metacat stylesheets, and all spaced is lumped together, creating undesired results.

A number of solutions are being considered and some are deployed in the development metacat at the LTER network office.

A broad approach would be to prepend an html

 tag wherever the user has specified within EML that the content should be treated as <literalLayout>.

Another broad approach is to plant <pre> tags in critical sections such as methodology descriptions (I.e: eml/dataset/methods/description/) or in inline data.

Other workarounds are to explore trimming white space in targeted locations (at beginning and end, not everywhere). There are a handful of different XSL treatments of whitespace, carriage returns, line feeds and new line characters discussed at


#1 Updated by Matt Jones over 15 years ago

Really this is more of an EML issue -- the EML Schema determines what layout and formatting are possible, and the XSLT stylesheets are maintained in the EML modules. I'm not sure how this should be fixed, and it requires broader discussion.

#2 Updated by Margaret O'Brien over 14 years ago

This bug is related to bug 3181, in which some elements typed xs:string may be chaned to ComplexType TextType to accomodate formatting.

#3 Updated by Margaret O'Brien about 14 years ago

other discussions:
additional discussion
literalLayout is a child of <para>, and this template could be added to eml-text.xsl to preserve it:

&lt;xsl:template match="literalLayout"&gt;


There is still lots of potential for ugliness, however. Here is additional discussion:

#4 Updated by Margaret O'Brien about 14 years ago

Inigo and Margaret will get together and discuss what changes to the txt:TextType will be necessary to accommodate common current uses. If these changes represent only additional optional elements added to the Type, they will be backward compatible.

#5 Updated by Redmine Admin over 9 years ago

Original Bugzilla ID was 2688

Also available in: Atom PDF