Hi Everyone, One of our deployments (so far) requires that taxonomic names be printed with certain formatting rules on their reports. For example, the genus, species, and supspecies/variety names must be italicized, while authors, infraspecific ranks, and cultivar names are not. In order to support this, we're considering adding a field alongside termDisplayName, probably called termFormattedDisplayName. This field would contain HTML, which would allow us to store a display name with rich styling applied. (At some point in the future, maybe we could even convince the UI team to add support for WYSIWYG editing of rich text fields.) Since it's somewhat painful to add fields to repeating groups, and even more painful to add fields to the repeating term group on authority items, I'd like to propose adding the termFormattedDisplayName field to the common schema. Is this something that other deployers would use? Thanks, Ray

PAHMA would also like this feature.

Hi Ray, PAHMA would also like this feature. Michael On Nov 27, 2012, at 1:30 PM, Ray Lee <rhlee@berkeley.edu> wrote: > Hi Everyone, > One of our deployments (so far) requires that taxonomic names be printed with certain formatting rules on their reports. For example, the genus, species, and supspecies/variety names must be italicized, while authors, infraspecific ranks, and cultivar names are not. In order to support this, we're considering adding a field alongside termDisplayName, probably called termFormattedDisplayName. This field would contain HTML, which would allow us to store a display name with rich styling applied. (At some point in the future, maybe we could even convince the UI team to add support for WYSIWYG editing of rich text fields.) > > Since it's somewhat painful to add fields to repeating groups, and even more painful to add fields to the repeating term group on authority items, I'd like to propose adding the termFormattedDisplayName field to the common schema. Is this something that other deployers would use? > > Thanks, > Ray > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

     PAHMA would also like this feature.

No objection from MMI. On Tue, Nov 27, 2012 at 5:43 PM, Michael T. Black <mtblack@berkeley.edu>wrote: > Hi Ray, > > PAHMA would also like this feature. > > Michael > > > On Nov 27, 2012, at 1:30 PM, Ray Lee <rhlee@berkeley.edu> wrote: > > > Hi Everyone, > > One of our deployments (so far) requires that taxonomic names be printed > with certain formatting rules on their reports. For example, the genus, > species, and supspecies/variety names must be italicized, while authors, > infraspecific ranks, and cultivar names are not. In order to support this, > we're considering adding a field alongside termDisplayName, probably called > termFormattedDisplayName. This field would contain HTML, which would allow > us to store a display name with rich styling applied. (At some point in the > future, maybe we could even convince the UI team to add support for WYSIWYG > editing of rich text fields.) > > > > Since it's somewhat painful to add fields to repeating groups, and even > more painful to add fields to the repeating term group on authority items, > I'd like to propose adding the termFormattedDisplayName field to the common > schema. Is this something that other deployers would use? > > > > Thanks, > > Ray > > _______________________________________________ > > Talk mailing list > > Talk@lists.collectionspace.org > > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > -- Megan Forbes Collection Manager Museum of the Moving Image 36-01 35 Avenue Astoria, NY 11106 movingimage.us 718 777 6800 Direct 718 777 6834

     PAHMA would also like this feature.

Would it not make sense to use a functional markup rather than a typographic markup for this? That is, instead of storing an HTML fragment, store an XML fragment that is then styled. I.e. (very schematic psuedocode follows!) Data: <termFormattedDisplayName> <genus>some genus</genus><author>John Doe></author>... </termFormattedDisplayName> Then css resembling: .genus { style: italic } .author { style: none} This would allow presentation to be changed without modifying the data, at the expense of having to style the data. If the typographic style for representing these elements is fixed, never going to change, and will not conflict with existing styling, then HTML is fine and a bit simpler to program around. Otherwise, the functional markup is likely to be more durable. And I'm guessing in either case the XML/HTML tags would need to be XML-encoded to hide the structure from the rest of the system? John On Mon, Dec 3, 2012 at 5:58 AM, Megan Forbes <mforbes@movingimage.us> wrote: > No objection from MMI. > > > On Tue, Nov 27, 2012 at 5:43 PM, Michael T. Black <mtblack@berkeley.edu> > wrote: >> >> Hi Ray, >> >> PAHMA would also like this feature. >> >> Michael >> >> >> On Nov 27, 2012, at 1:30 PM, Ray Lee <rhlee@berkeley.edu> wrote: >> >> > Hi Everyone, >> > One of our deployments (so far) requires that taxonomic names be printed >> > with certain formatting rules on their reports. For example, the genus, >> > species, and supspecies/variety names must be italicized, while authors, >> > infraspecific ranks, and cultivar names are not. In order to support this, >> > we're considering adding a field alongside termDisplayName, probably called >> > termFormattedDisplayName. This field would contain HTML, which would allow >> > us to store a display name with rich styling applied. (At some point in the >> > future, maybe we could even convince the UI team to add support for WYSIWYG >> > editing of rich text fields.) >> > >> > Since it's somewhat painful to add fields to repeating groups, and even >> > more painful to add fields to the repeating term group on authority items, >> > I'd like to propose adding the termFormattedDisplayName field to the common >> > schema. Is this something that other deployers would use? >> > >> > Thanks, >> > Ray >> > _______________________________________________ >> > Talk mailing list >> > Talk@lists.collectionspace.org >> > >> > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > > > -- > Megan Forbes > Collection Manager > > Museum of the Moving Image > 36-01 35 Avenue Astoria, NY 11106 > movingimage.us 718 777 6800 > Direct 718 777 6834 > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >

     PAHMA would also like this feature.

That's not a bad idea, but HTML also separates content from presentation, so <em> and <strong> tags are in that spirit and easier for others to share. Also, not sure if all presentation engines (reports, etc) support good CSS, and the HTML tags will revert to styled variants. Patrick "John B. LOWE" <jblowe@berkeley.edu> wrote: >Would it not make sense to use a functional markup rather than a >typographic markup for this? That is, instead of storing an HTML >fragment, store an XML fragment that is then styled. > >I.e. (very schematic psuedocode follows!) > >Data: > ><termFormattedDisplayName> > <genus>some genus</genus><author>John Doe></author>... ></termFormattedDisplayName> > > >Then css resembling: > >.genus { style: italic } >.author { style: none} > >This would allow presentation to be changed without modifying the >data, at the expense of having to style the data. If the typographic >style for representing these elements is fixed, never going to change, >and will not conflict with existing styling, then HTML is fine and a >bit simpler to program around. Otherwise, the functional markup is >likely to be more durable. > >And I'm guessing in either case the XML/HTML tags would need to be >XML-encoded to hide the structure from the rest of the system? > >John > >On Mon, Dec 3, 2012 at 5:58 AM, Megan Forbes <mforbes@movingimage.us> >wrote: >> No objection from MMI. >> >> >> On Tue, Nov 27, 2012 at 5:43 PM, Michael T. Black ><mtblack@berkeley.edu> >> wrote: >>> >>> Hi Ray, >>> >>> PAHMA would also like this feature. >>> >>> Michael >>> >>> >>> On Nov 27, 2012, at 1:30 PM, Ray Lee <rhlee@berkeley.edu> wrote: >>> >>> > Hi Everyone, >>> > One of our deployments (so far) requires that taxonomic names be >printed >>> > with certain formatting rules on their reports. For example, the >genus, >>> > species, and supspecies/variety names must be italicized, while >authors, >>> > infraspecific ranks, and cultivar names are not. In order to >support this, >>> > we're considering adding a field alongside termDisplayName, >probably called >>> > termFormattedDisplayName. This field would contain HTML, which >would allow >>> > us to store a display name with rich styling applied. (At some >point in the >>> > future, maybe we could even convince the UI team to add support >for WYSIWYG >>> > editing of rich text fields.) >>> > >>> > Since it's somewhat painful to add fields to repeating groups, and >even >>> > more painful to add fields to the repeating term group on >authority items, >>> > I'd like to propose adding the termFormattedDisplayName field to >the common >>> > schema. Is this something that other deployers would use? >>> > >>> > Thanks, >>> > Ray >>> > _______________________________________________ >>> > Talk mailing list >>> > Talk@lists.collectionspace.org >>> > >>> > >http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> >>> >http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >> >> >> >> -- >> Megan Forbes >> Collection Manager >> >> Museum of the Moving Image >> 36-01 35 Avenue Astoria, NY 11106 >> movingimage.us 718 777 6800 >> Direct 718 777 6834 >> >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> >http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> > >_______________________________________________ >Talk mailing list >Talk@lists.collectionspace.org >http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Hi Ray, We recently also had a request to support italics in a collectionobject title (specifically for a series of artworks which include the Latin name of the subject species in the title, as seen here http://pinterest.com/statensmuseum/gottorfer-codex/ ). We have no immediate plans to enable this functionality, but can see there's a possibility that your solution to this problem could be adapted or reused later to help us and others address the same issue elsewhere in the schemas. Regards, Chris ________________________________ Fra: Talk [mailto:talk-bounces@lists.collectionspace.org] På vegne af Ray Lee Sendt: 27. november 2012 22:30 Til: CollectionSpace Talk List Emne: [Talk] a new field proposal for taxon records Hi Everyone, One of our deployments (so far) requires that taxonomic names be printed with certain formatting rules on their reports. For example, the genus, species, and supspecies/variety names must be italicized, while authors, infraspecific ranks, and cultivar names are not. In order to support this, we're considering adding a field alongside termDisplayName, probably called termFormattedDisplayName. This field would contain HTML, which would allow us to store a display name with rich styling applied. (At some point in the future, maybe we could even convince the UI team to add support for WYSIWYG editing of rich text fields.) Since it's somewhat painful to add fields to repeating groups, and even more painful to add fields to the repeating term group on authority items, I'd like to propose adding the termFormattedDisplayName field to the common schema. Is this something that other deployers would use? Thanks, Ray

     PAHMA would also like this feature.

Note also John, that the contents of this field will be set by custom script, so each implementor can do whatever they want. AIUI, the proposal does not include an HTML editor widget or anything like that. We (services) are probably going to add this field to the schemas, but will not change all the UI templates (implementors can do so as needed). ChrisH needs it for taxon, but we are inclined to add it to all the auths for consistency. I think Ray has UI for it in Taxon, which we can commit that as well, as a demo. Comments? Patrick "John B. LOWE" <jblowe@berkeley.edu> wrote: >Would it not make sense to use a functional markup rather than a >typographic markup for this? That is, instead of storing an HTML >fragment, store an XML fragment that is then styled. > >I.e. (very schematic psuedocode follows!) > >Data: > ><termFormattedDisplayName> > <genus>some genus</genus><author>John Doe></author>... ></termFormattedDisplayName> > > >Then css resembling: > >.genus { style: italic } >.author { style: none} > >This would allow presentation to be changed without modifying the >data, at the expense of having to style the data. If the typographic >style for representing these elements is fixed, never going to change, >and will not conflict with existing styling, then HTML is fine and a >bit simpler to program around. Otherwise, the functional markup is >likely to be more durable. > >And I'm guessing in either case the XML/HTML tags would need to be >XML-encoded to hide the structure from the rest of the system? > >John > >On Mon, Dec 3, 2012 at 5:58 AM, Megan Forbes <mforbes@movingimage.us> >wrote: >> No objection from MMI. >> >> >> On Tue, Nov 27, 2012 at 5:43 PM, Michael T. Black ><mtblack@berkeley.edu> >> wrote: >>> >>> Hi Ray, >>> >>> PAHMA would also like this feature. >>> >>> Michael >>> >>> >>> On Nov 27, 2012, at 1:30 PM, Ray Lee <rhlee@berkeley.edu> wrote: >>> >>> > Hi Everyone, >>> > One of our deployments (so far) requires that taxonomic names be >printed >>> > with certain formatting rules on their reports. For example, the >genus, >>> > species, and supspecies/variety names must be italicized, while >authors, >>> > infraspecific ranks, and cultivar names are not. In order to >support this, >>> > we're considering adding a field alongside termDisplayName, >probably called >>> > termFormattedDisplayName. This field would contain HTML, which >would allow >>> > us to store a display name with rich styling applied. (At some >point in the >>> > future, maybe we could even convince the UI team to add support >for WYSIWYG >>> > editing of rich text fields.) >>> > >>> > Since it's somewhat painful to add fields to repeating groups, and >even >>> > more painful to add fields to the repeating term group on >authority items, >>> > I'd like to propose adding the termFormattedDisplayName field to >the common >>> > schema. Is this something that other deployers would use? >>> > >>> > Thanks, >>> > Ray >>> > _______________________________________________ >>> > Talk mailing list >>> > Talk@lists.collectionspace.org >>> > >>> > >http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> >>> >http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >> >> >> >> -- >> Megan Forbes >> Collection Manager >> >> Museum of the Moving Image >> 36-01 35 Avenue Astoria, NY 11106 >> movingimage.us 718 777 6800 >> Direct 718 777 6834 >> >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> >http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> > >_______________________________________________ >Talk mailing list >Talk@lists.collectionspace.org >http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

I agree that the format of the content of the field should be left up to implementers. The choice, I think, will largely depend on where the field will be used. For us, it's primarily in reports, so we're limited to what JasperReports supports, which is RTF, HTML, and their own proprietary markup. HTML would be the most interoperable choice. Annoyingly, JasperReports does not properly render <em> and <strong> tags, so we can't use them, as much as it's the right thing to do. It does correctly render <i>, <b>, <span style="font-style: italic">, and <span style="font-weight: bold">. We'll probably be going with the latter two, since they at least are valid HTML 4+. References: http://jasperreports.sourceforge.net/sample.reference/markup/index.html http://community.jaspersoft.com/jasperreports-library/issues/4842 While this proposal doesn't prescribe that HTML be used, or that there be an HTML editor widget, I think a rich text editor widget that we can apply as a decorator to text fields is something that will be useful in the future. Once we start driving public facing web sites out of CollectionSpace, users will start to ask how to put italics, superscripts, bullets, and links in their object descriptions (or other fields). Thanks, Ray On Tue, Dec 4, 2012 at 7:53 AM, Patrick Schmitz <pschmitz@berkeley.edu>wrote: > Note also John, that the contents of this field will be set by custom > script, so each implementor can do whatever they want. AIUI, the proposal > does not include an HTML editor widget or anything like that. > > We (services) are probably going to add this field to the schemas, but > will not change all the UI templates (implementors can do so as needed). > ChrisH needs it for taxon, but we are inclined to add it to all the auths > for consistency. I think Ray has UI for it in Taxon, which we can commit > that as well, as a demo. Comments? > > Patrick > > "John B. LOWE" <jblowe@berkeley.edu> wrote: > >> Would it not make sense to use a functional markup rather than a >> typographic markup for this? That is, instead of storing an HTML >> fragment, store an XML fragment that is then styled. >> >> I.e. (very schematic psuedocode follows!) >> >> Data: >> >> <termFormattedDisplayName> >> <genus>some genus</genus><author>John Doe></author>... >> </termFormattedDisplayName> >> >> >> Then css resembling: >> >> .genus { style: italic } >> .author { style: none} >> >> This would allow presentation to be changed without modifying the >> data, at the expense of having to style the data. If the typographic >> style for representing these elements is fixed, never going to change, >> and will not conflict with existing styling, then HTML is fine and a >> bit simpler to program around. Otherwise, the >> functional markup is >> likely to be more durable. >> >> And I'm guessing in either case the XML/HTML tags would need to be >> XML-encoded to hide the structure from the rest of the system? >> >> John >> >> On Mon, Dec 3, 2012 at 5:58 AM, Megan Forbes <mforbes@movingimage.us> wrote: >> >>> No objection from MMI. >>> >>> >>> On Tue, Nov 27, 2012 at 5:43 PM, Michael T. Black <mtblack@berkeley.edu> >>> wrote: >>> >>> Hi Ray, >>>> >>>> PAHMA would also like this feature. >>>> >>>> Michael >>>> >>>> >>>> On Nov 27, 2012, at 1:30 PM, Ray Lee <rhlee@berkeley.edu> wrote: >>>> >>>> Hi >>>>> Everyone, >>>>> One of our deployments (so far) requires that taxonomic names be printed >>>>> with certain formatting rules on their reports. For example, the genus, >>>>> species, and supspecies/variety names must be italicized, while authors, >>>>> infraspecific ranks, and cultivar names are not. In order to support this, >>>>> we're considering adding a field alongside termDisplayName, probably called >>>>> termFormattedDisplayName. This field would contain HTML, which would allow >>>>> us to store a display name with rich styling applied. (At some point in the >>>>> future, maybe we could even convince the UI team to add support for WYSIWYG >>>>> editing of rich text fields.) >>>>> >>>>> Since it's somewhat painful to add fields to repeating groups, and even >>>>> more painful to add fields to the repeating term group on authority items, >>>>> I'd like to propose adding the termFormattedDisplayName field to the common >>>>> schema. Is this something that other deployers would use? >>>>> >>>>> Thanks, >>>>> Ray >>>>> ------------------------------ >>>>> >>>>> Talk mailing list >>>>> Talk@lists.collectionspace.org >>>>> >>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>>> >>>> >>>> >>>> ------------------------------ >>>> >>>> Talk mailing list >>>> Talk@lists.collectionspace.org >>>> >>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>> >>> >>> >>> >>> >>> -- >>> Megan Forbes >>> Collection Manager >>> >>> Museum of the Moving Image >>> 36-01 35 Avenue Astoria, NY 11106 >>> movingimage.us 718 777 6800 >>> Direct 718 777 6834 >>> >>> >>> >>> ------------------------------ >>> >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >> >> >> ------------------------------ >> >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >> > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

Hi Everyone, Some additional thoughts on how best to represent italicized taxonomic names in the proposed termFormattedDisplayName field: As I mentioned earlier, there are basically three ways to produce italicized text in html: the <em> tag, the <i> tag, and the style attribute on an arbitrary tag, e.g. <span style="font-style: italic">. Unlike most HTML renderers, JasperReports doesn't render <em> in italics, so it's not a good choice, if the primary use for the field is in reports generated by Jasper. I had assumed that HTML5 would obsolete the <i> tag along with other presentational elements, leaving just the <span style ...> option for long-term interoperability. However, this isn't the case. In fact, the <i>tag is staying in HTML5, and is being redefined to suit our purposes nicely. From http://dev.w3.org/html5/html4-differences/#changed-elements: - The i<http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-i-element> element now represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name in Western texts This makes <i> semantically the best option, as well as the most concise, and the easiest for users to edit in the absence of an HTML editor. Thanks, Ray On Tue, Dec 4, 2012 at 4:06 PM, Ray Lee <rhlee@berkeley.edu> wrote: > I agree that the format of the content of the field should be left up to > implementers. The choice, I think, will largely depend on where the field > will be used. For us, it's primarily in reports, so we're limited to what > JasperReports supports, which is RTF, HTML, and their own proprietary > markup. HTML would be the most interoperable choice. > > Annoyingly, JasperReports does not properly render <em> and <strong> tags, > so we can't use them, as much as it's the right thing to do. It does > correctly render <i>, <b>, <span style="font-style: italic">, and <span > style="font-weight: bold">. We'll probably be going with the latter two, > since they at least are valid HTML 4+. > > References: > http://jasperreports.sourceforge.net/sample.reference/markup/index.html > http://community.jaspersoft.com/jasperreports-library/issues/4842 > > While this proposal doesn't prescribe that HTML be used, or that there be > an HTML editor widget, I think a rich text editor widget that we can apply > as a decorator to text fields is something that will be useful in the > future. Once we start driving public facing web sites out of > CollectionSpace, users will start to ask how to put italics, superscripts, > bullets, and links in their object descriptions (or other fields). > > Thanks, > Ray > > > > On Tue, Dec 4, 2012 at 7:53 AM, Patrick Schmitz <pschmitz@berkeley.edu>wrote: > >> Note also John, that the contents of this field will be set by custom >> script, so each implementor can do whatever they want. AIUI, the proposal >> does not include an HTML editor widget or anything like that. >> >> We (services) are probably going to add this field to the schemas, but >> will not change all the UI templates (implementors can do so as needed). >> ChrisH needs it for taxon, but we are inclined to add it to all the auths >> for consistency. I think Ray has UI for it in Taxon, which we can commit >> that as well, as a demo. Comments? >> >> Patrick >> >> "John B. LOWE" <jblowe@berkeley.edu> wrote: >> >>> Would it not make sense to use a functional markup rather than a >>> typographic markup for this? That is, instead of storing an HTML >>> >>> fragment, store an XML fragment that is then styled. >>> >>> I.e. (very schematic psuedocode follows!) >>> >>> Data: >>> >>> <termFormattedDisplayName> >>> <genus>some genus</genus><author>John Doe></author>... >>> >>> </termFormattedDisplayName> >>> >>> >>> Then css resembling: >>> >>> .genus { style: italic } >>> .author { style: none} >>> >>> This would allow presentation to be changed without modifying the >>> data, at the expense of having to style the data. If the typographic >>> >>> style for representing these elements is fixed, never going to change, >>> and will not conflict with existing styling, then HTML is fine and a >>> bit simpler to program around. Otherwise, the >>> functional markup is >>> likely to be more durable. >>> >>> And I'm guessing in either case the XML/HTML tags would need to be >>> XML-encoded to hide the structure from the rest of the system? >>> >>> John >>> >>> On Mon, Dec 3, 2012 at 5:58 AM, Megan Forbes <mforbes@movingimage.us> wrote: >>> >>>> No objection from MMI. >>>> >>>> >>>> On Tue, Nov 27, 2012 at 5:43 PM, Michael T. Black <mtblack@berkeley.edu> >>>> >>>> wrote: >>>> >>>> Hi Ray, >>>>> >>>>> PAHMA would also like this feature. >>>>> >>>>> Michael >>>>> >>>>> >>>>> On Nov 27, 2012, at 1:30 PM, Ray Lee <rhlee@berkeley.edu> wrote: >>>>> >>>>> Hi >>>>>> Everyone, >>>>>> One of our deployments (so far) requires that taxonomic names be printed >>>>>> with certain formatting rules on their reports. For example, the genus, >>>>>> species, and supspecies/variety names must be italicized, while authors, >>>>>> >>>>>> infraspecific ranks, and cultivar names are not. In order to support this, >>>>>> we're considering adding a field alongside termDisplayName, probably called >>>>>> termFormattedDisplayName. This field would contain HTML, which would allow >>>>>> >>>>>> us to store a display name with rich styling applied. (At some point in the >>>>>> future, maybe we could even convince the UI team to add support for WYSIWYG >>>>>> editing of rich text fields.) >>>>>> >>>>>> Since it's somewhat painful to add fields to repeating groups, and even >>>>>> >>>>>> more painful to add fields to the repeating term group on authority items, >>>>>> I'd like to propose adding the termFormattedDisplayName field to the common >>>>>> schema. Is this something that other deployers would use? >>>>>> >>>>>> Thanks, >>>>>> Ray >>>>>> ------------------------------ >>>>>> >>>>>> Talk mailing list >>>>>> Talk@lists.collectionspace.org >>>>>> >>>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> Talk mailing list >>>>> Talk@lists.collectionspace.org >>>>> >>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Megan Forbes >>>> Collection Manager >>>> >>>> Museum of the Moving Image >>>> 36-01 35 Avenue Astoria, NY 11106 >>>> movingimage.us 718 777 6800 >>>> >>>> Direct 718 777 6834 >>>> >>>> >>>> >>>> ------------------------------ >>>> >>>> Talk mailing list >>>> Talk@lists.collectionspace.org >>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>> >>> >>> >>> ------------------------------ >>> >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >>> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> >> _______________________________________________ >> >> Talk mailing list >> Talk@lists.collectionspace.org >> >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >> >

-

The i<http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-i-element> element
now represents a span of text in an alternate voice or mood, or otherwise
offset from the normal prose in a manner indicating a different quality of
text, such as a taxonomic designation, a technical term, an idiomatic
phrase from another language, a thought, or a ship name in Western texts

I agree with Ray. Even through it's somewhat deprecated, the <i/> tag is concise and easy to remember. Some collections may already use this tag in their field data so it will be good to have this backward compatibility in place. - Jesse On Thu, Dec 6, 2012 at 3:16 PM, Ray Lee <rhlee@berkeley.edu> wrote: > Hi Everyone, > Some additional thoughts on how best to represent italicized taxonomic > names in the proposed termFormattedDisplayName field: > > As I mentioned earlier, there are basically three ways to produce > italicized text in html: the <em> tag, the <i> tag, and the style > attribute on an arbitrary tag, e.g. <span style="font-style: italic">. > Unlike most HTML renderers, JasperReports doesn't render <em> in italics, > so it's not a good choice, if the primary use for the field is in reports > generated by Jasper. > > I had assumed that HTML5 would obsolete the <i> tag along with other > presentational elements, leaving just the <span style ...> option for > long-term interoperability. However, this isn't the case. In fact, the <i>tag is staying in HTML5, and is being redefined to suit our purposes > nicely. From http://dev.w3.org/html5/html4-differences/#changed-elements: > > - > > The i<http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-i-element> element > now represents a span of text in an alternate voice or mood, or otherwise > offset from the normal prose in a manner indicating a different quality of > text, such as a taxonomic designation, a technical term, an idiomatic > phrase from another language, a thought, or a ship name in Western texts > > This makes <i> semantically the best option, as well as the most concise, > and the easiest for users to edit in the absence of an HTML editor. > > Thanks, > Ray > > > > On Tue, Dec 4, 2012 at 4:06 PM, Ray Lee <rhlee@berkeley.edu> wrote: > >> I agree that the format of the content of the field should be left up to >> implementers. The choice, I think, will largely depend on where the field >> will be used. For us, it's primarily in reports, so we're limited to what >> JasperReports supports, which is RTF, HTML, and their own proprietary >> markup. HTML would be the most interoperable choice. >> >> Annoyingly, JasperReports does not properly render <em> and <strong> >> tags, so we can't use them, as much as it's the right thing to do. It does >> correctly render <i>, <b>, <span style="font-style: italic">, and <span >> style="font-weight: bold">. We'll probably be going with the latter two, >> since they at least are valid HTML 4+. >> >> References: >> http://jasperreports.sourceforge.net/sample.reference/markup/index.html >> http://community.jaspersoft.com/jasperreports-library/issues/4842 >> >> While this proposal doesn't prescribe that HTML be used, or that there be >> an HTML editor widget, I think a rich text editor widget that we can apply >> as a decorator to text fields is something that will be useful in the >> future. Once we start driving public facing web sites out of >> CollectionSpace, users will start to ask how to put italics, superscripts, >> bullets, and links in their object descriptions (or other fields). >> >> Thanks, >> Ray >> >> >> >> On Tue, Dec 4, 2012 at 7:53 AM, Patrick Schmitz <pschmitz@berkeley.edu>wrote: >> >>> Note also John, that the contents of this field will be set by custom >>> script, so each implementor can do whatever they want. AIUI, the proposal >>> does not include an HTML editor widget or anything like that. >>> >>> We (services) are probably going to add this field to the schemas, but >>> will not change all the UI templates (implementors can do so as needed). >>> ChrisH needs it for taxon, but we are inclined to add it to all the auths >>> for consistency. I think Ray has UI for it in Taxon, which we can commit >>> that as well, as a demo. Comments? >>> >>> Patrick >>> >>> "John B. LOWE" <jblowe@berkeley.edu> wrote: >>> >>>> Would it not make sense to use a functional markup rather than a >>>> typographic markup for this? That is, instead of storing an HTML >>>> >>>> >>>> fragment, store an XML fragment that is then styled. >>>> >>>> I.e. (very schematic psuedocode follows!) >>>> >>>> Data: >>>> >>>> <termFormattedDisplayName> >>>> <genus>some genus</genus><author>John Doe></author>... >>>> >>>> >>>> </termFormattedDisplayName> >>>> >>>> >>>> Then css resembling: >>>> >>>> .genus { style: italic } >>>> .author { style: none} >>>> >>>> This would allow presentation to be changed without modifying the >>>> data, at the expense of having to style the data. If the typographic >>>> >>>> >>>> style for representing these elements is fixed, never going to change, >>>> and will not conflict with existing styling, then HTML is fine and a >>>> bit simpler to program around. Otherwise, the >>>> functional markup is >>>> likely to be more durable. >>>> >>>> And I'm guessing in either case the XML/HTML tags would need to be >>>> XML-encoded to hide the structure from the rest of the system? >>>> >>>> John >>>> >>>> On Mon, Dec 3, 2012 at 5:58 AM, Megan Forbes <mforbes@movingimage.us> wrote: >>>> >>>> No objection from MMI. >>>>> >>>>> >>>>> On Tue, Nov 27, 2012 at 5:43 PM, Michael T. Black <mtblack@berkeley.edu> >>>>> >>>>> >>>>> wrote: >>>>> >>>>> Hi Ray, >>>>>> >>>>>> PAHMA would also like this feature. >>>>>> >>>>>> Michael >>>>>> >>>>>> >>>>>> On Nov 27, 2012, at 1:30 PM, Ray Lee <rhlee@berkeley.edu> wrote: >>>>>> >>>>>> >>>>>>> Hi >>>>>>> Everyone, >>>>>>> One of our deployments (so far) requires that taxonomic names be printed >>>>>>> with certain formatting rules on their reports. For example, the genus, >>>>>>> species, and supspecies/variety names must be italicized, while authors, >>>>>>> >>>>>>> >>>>>>> infraspecific ranks, and cultivar names are not. In order to support this, >>>>>>> we're considering adding a field alongside termDisplayName, probably called >>>>>>> termFormattedDisplayName. This field would contain HTML, which would allow >>>>>>> >>>>>>> >>>>>>> us to store a display name with rich styling applied. (At some point in the >>>>>>> future, maybe we could even convince the UI team to add support for WYSIWYG >>>>>>> editing of rich text fields.) >>>>>>> >>>>>>> Since it's somewhat painful to add fields to repeating groups, and even >>>>>>> >>>>>>> >>>>>>> more painful to add fields to the repeating term group on authority items, >>>>>>> I'd like to propose adding the termFormattedDisplayName field to the common >>>>>>> schema. Is this something that other deployers would use? >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Ray >>>>>>> ------------------------------ >>>>>>> >>>>>>> Talk mailing list >>>>>>> Talk@lists.collectionspace.org >>>>>>> >>>>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>>>>> >>>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> >>>>>> Talk mailing list >>>>>> Talk@lists.collectionspace.org >>>>>> >>>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Megan Forbes >>>>> Collection Manager >>>>> >>>>> Museum of the Moving Image >>>>> 36-01 35 Avenue Astoria, NY 11106 >>>>> movingimage.us 718 777 6800 >>>>> >>>>> >>>>> Direct 718 777 6834 >>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> Talk mailing list >>>>> Talk@lists.collectionspace.org >>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>>> >>>>> >>>> >>>> ------------------------------ >>>> >>>> Talk mailing list >>>> Talk@lists.collectionspace.org >>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>> >>>> >>> -- >>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >>> >>> _______________________________________________ >>> >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >>> >> > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >