styling design question

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

styling design question

Bruce D'Arcus-3
Hi,

I've been talking to the OpenDocument people about the possibility of
including the citation style language (CSL) I designed in OpenDocument
in some form.

http://xbiblio.sourceforge.net/csl.html

One issue they raised is that it doesn't really make use of the OD
styling infrastructure.  So I've been experimenting a bit with what it
might mean to bring them closer in line.

Basically, it would primarily mean moving a lot of element content into
attributes.  This fragment, for example, is about 75% more compact than
my current schema, and more in line with an OD approach:

     <names initialize-with="." and-as=" &amp;"/>
     <months jan="Jan" feb="Feb" mar="Mar" apr="Apr" may="May" jun="Jun"
       jul="Jul" aug="Aug" sep="Sep" oct="Oct" nov="Nov" dec="Dec"/>
     <locator unit="page" use-when="missing-volume-issue" single="p. "
       multiple="pp. "/>
     <locator unit="paragraph" single="¶ " multiple="¶¶ "/>
     <role term="editor" single="Ed. " multiple="Eds. "/>
     <role term="translator" single="tran. " multiple="trans. "/>
     <genre term="dissertation" value="PhD Dissertation"/>
     <genre term="letter" value="letter"/>
     <genre term="press release" value="press release"/>
     <genre term="memo" value="memo"/>
     <medium term="cdrom" value="CD-ROM"/>

OK, so it's a lot more compact (and probably faster to process as a
result).  What we give up with this approach is any possibility to add
markup to attribute content.  So for example, current OOo code to
handle prefixes and suffixes for citations is handled in attributes.  
Hence, they can only ever be strings effectively.

Is that a reasonable tradeoff?  How much of a compromise would it be
worth it to get this into the OD file format?

And thinking about the document I posted the other day, how would
people imagine configuring the styling for the example which has:

author name
... citation 1 ...
.... citation 2 ...

In other words, how would you see configuring a GUI such that you
indicate that a) citations should be grouped by author, and b) that the
group ought to be labeled with the author name, followed by a paragraph
break? It might have bearing on the above.

Bruce


Reply | Threaded
Open this post in threaded view
|

Re: styling design question

Johan Kool
Could you do this?

    <role term="editor" single="Ed. " multiple="Eds. " font-style-prefix="italic" font-style="regular" />

where font-style is the mark-up used for the editors name and font-style-prefix (and -suffix) are used for the markup of those. That should handle most needs, right? So the above should result in something like:
Johan Kool Ed.

I'm by far not a XML expert, so I hope this makes sense.

Johan

Reply | Threaded
Open this post in threaded view
|

Re: styling design question

Bruce D'Arcus-3
On Oct 3, 2005, at 8:59 PM, Johan Kool wrote:

> Could you do this?
>
>     <role term="editor" single="Ed. " multiple="Eds. "
> font-style-prefix="italic" font-style="regular" />
>
> where font-style is the mark-up used for the editors name and
> font-style-prefix (and -suffix) are used for the markup of those. That
> should handle most needs, right? So the above should result in
> something like:
>
>         Johan Kool Ed.
>
> I'm by far not a XML expert, so I hope this makes sense.

Yes, it makes sense.  However, the OD standard uses FO for font
styling, so that in reality you end up with something like:

<csl:role text:prefix="Ed. " fo:font-style="italic" ... />

... and I'm pretty sure FO has no such font-style-prefix attribute.

Have you seen examples where "Ed." is italicized like that?

Bruce



Reply | Threaded
Open this post in threaded view
|

Re: styling design question

Matthias Steffens
On 03-Oct-2005 at 21:21 -0400 Bruce D'Arcus wrote:

> Have you seen examples where "Ed." is italicized like that?

I'm currently writing a paper for a journal that requires
"ed./eds." to be printed in italic.

I guess it would be too much work to support both CSL schemas, so
that others who require this feature and want to use CSL outside
of OOo can make use of it?

However, I think that having CSL included into the OpenDocument
format would be a very good thing. Best option would be to press
them to support styled prefixes and suffixes. ;-) Well, at least
it's a valid feature request from a user point of view.

Regards, Matthias


Reply | Threaded
Open this post in threaded view
|

Re: styling design question

Bruce D'Arcus-3
On Oct 4, 2005, at 4:23 AM, Matthias Steffens wrote:

> On 03-Oct-2005 at 21:21 -0400 Bruce D'Arcus wrote:
>
>> Have you seen examples where "Ed." is italicized like that?
>
> I'm currently writing a paper for a journal that requires
> "ed./eds." to be printed in italic.

Well that settles it then; it stays as it is in that case :-)

> I guess it would be too much work to support both CSL schemas, so
> that others who require this feature and want to use CSL outside
> of OOo can make use of it?

Yes, it'd be too much work.  The challenge in this case is not really
the XML anyway, but the GUI to edit it.

> However, I think that having CSL included into the OpenDocument
> format would be a very good thing. Best option would be to press
> them to support styled prefixes and suffixes. ;-) Well, at least
> it's a valid feature request from a user point of view.

Yes, and I think that's what I need to make a case.

Bruce



Reply | Threaded
Open this post in threaded view
|

Re: styling design question

Bruce D'Arcus-3
In reply to this post by Matthias Steffens
On Oct 4, 2005, at 4:23 AM, Matthias Steffens wrote:

> On 03-Oct-2005 at 21:21 -0400 Bruce D'Arcus wrote:
>
>> Have you seen examples where "Ed." is italicized like that?
>
> I'm currently writing a paper for a journal that requires
> "ed./eds." to be printed in italic.

Actually, correction here:

This example would still work in the alternate approach, as the "Ed."
content is actually handled with the role element:

<csl:role text:prefix=" " text:value="Ed." fo:font-style="italic"/>

As I see it, the prefix/suffix stuff is really for punctuation.

Bruce



Reply | Threaded
Open this post in threaded view
|

Re: styling design question

Johan Kool
In reply to this post by Bruce D'Arcus-3
Do I understand it correctly that
- a prefix or suffix can not have its own markup?
- extra text such as Ed./Eds. and p./pp. can have its own markup?

If you go with the assumption that the prefix/suffix wil always use the same
markup as the data in question, e.g. (2005) will be all bold, than I think
you have a big majority of citations covered. I think that wanting the
brackets to be italic and the year to be bold are rare occasions.

Johan

________________________________________________
Message sent using
Mailophalen 0.2.7.2


Reply | Threaded
Open this post in threaded view
|

Re: styling design question

Bruce D'Arcus-3
On Oct 4, 2005, at 8:40 AM, Johan Kool wrote:

> Do I understand it correctly that
> - a prefix or suffix can not have its own markup?
> - extra text such as Ed./Eds. and p./pp. can have its own markup?

Correct.

Bruce



Reply | Threaded
Open this post in threaded view
|

GUI mockup

Johan Kool
My second attempt to send this file seems to have failed too.  
SourceForge doesn't accept zip files. Download the file here: http://
sheba.geo.vu.nl/~jkool/filearea/GUI%20CSL.zip

Just a plain and quick mockup for a CSL GUI in IB for OS X. Clearly  
not finished...

The empty lists should hold all the options, article, book-chapter,  
editor, translator etc. The font style, prefix and suffix fields  
should only be enabled when a token in NSTokenField is selected. The  
current implementation for NSTokenField doesn't allow this, but it's  
close enough to show my intentions. The plus button should show a  
list with options to choose from. Multiple author stuff is not any  
good yet. There are stil plenty alignment issues.

I hope this is any help/good. :-)

Johan



Reply | Threaded
Open this post in threaded view
|

Re: GUI mockup

Bruce D'Arcus-3
Johan Kool wrote:
> My second attempt to send this file seems to have failed too.
> SourceForge doesn't accept zip files. Download the file here:
> http://sheba.geo.vu.nl/~jkool/filearea/GUI%20CSL.zip
>
> Just a plain and quick mockup for a CSL GUI in IB for OS X. Clearly not
> finished...

Cool!  Except, I can't seem to get it to open right on my box.

While opening “GUI CSL.nib”, the following error occured:

*** -[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of
class (NSTokenField)

A screenshot perhaps?

Bruce


Reply | Threaded
Open this post in threaded view
|

Re: GUI mockup

Johan Kool
Ah, you'll need 10.4 for this.

Here are some screenshots:

There are 4 windows now. The most Mac way, would, I think, be by  
using a toolbar with some nice icons.


Sources has two columns, the first column being a popup, that can be  
used to indicate the type of the source, e.g. URL.



The left list should hold the items page, paragraph etc.



The left list should hold the items editor, translator etc.




The left list should hold the items book, chapter etc.


pastedGraphic.png (52K) Download Attachment
pastedGraphic.png (26K) Download Attachment
pastedGraphic.png (33K) Download Attachment
pastedGraphic.png (34K) Download Attachment
pastedGraphic.png (39K) Download Attachment
pastedGraphic.png (26K) Download Attachment
pastedGraphic.png (38K) Download Attachment
pastedGraphic.png (40K) Download Attachment
pastedGraphic.png (41K) Download Attachment
pastedGraphic.png (33K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GUI mockup

Johan Kool
In reply to this post by Bruce D'Arcus-3
Missed a crucial part on this sentence:

There are 4 windows now. The most Mac way to switch between these,  
would, I think, be by using a toolbar with some nice icons. Like the  
preference windows in many OS X apps.

Johan



Reply | Threaded
Open this post in threaded view
|

Re: GUI mockup

Bruce D'Arcus-3
In reply to this post by Johan Kool
Really nice Johan!

So are you planning to develop this into something, or were you just
playing with understanding how feasible it'd be?

One thing of note is how you'd handle the layout nesting.  For example,
your "Author" field should be:

creator
    name
    role

And then there's the container element.  How easy is that nesting to handle?

Bruce

PS - Mind if I blog about this and use a screenshot or two?


Reply | Threaded
Open this post in threaded view
|

Re: GUI mockup

Johan Kool

Op 4-okt-2005, om 20:00 heeft Bruce D'Arcus het volgende geschreven:

> Really nice Johan!
>
> So are you planning to develop this into something, or were you  
> just playing with understanding how feasible it'd be?

Not sure yet what I'll do.

> One thing of note is how you'd handle the layout nesting.  For  
> example, your "Author" field should be:
>
> creator
>    name
>    role

Something like this?





> And then there's the container element.  How easy is that nesting  
> to handle?

I could use insert another of those layout fields in the options for  
the selected token.. eh.. a picture is easier I guess.. :-)



I hope there can not be a container within a container? I can't  
imagine any journal wanting to have such a reference in its articles!


>
> Bruce
>
> PS - Mind if I blog about this and use a screenshot or two?

No problem.

>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,  
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> xbiblio-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>


pastedGraphic.png (37K) Download Attachment
pastedGraphic.png (47K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GUI mockup

Bruce D'Arcus-3
Johan Kool wrote:

>> One thing of note is how you'd handle the layout nesting.  For
>> example, your "Author" field should be:
>>
>> creator
>>    name
>>    role
>
> Something like this?

No, because the names and role are nested.  One finds a similar thing
with the origin field, in order to get (New York: ABC Books).

> I hope there can not be a container within a container? I can't imagine
> any journal wanting to have such a reference in its articles!

You certainly could for books: chapter, book, series.

I ask about this because I've considered whether it might make sense to
reconsider this.  There are definite advantages to this approach from a
processing standpoint, because it makes it easy to handle punctuation.
Going to a flat model would make some things more difficult. But it does
become more tricky from a GUI perspective to keep it nested.

Bruce


Reply | Threaded
Open this post in threaded view
|

Re: GUI mockup

Bruce D'Arcus-3
Oh, this page has a mockup I did in HTML of the nesting:

<http://xbiblio.sourceforge.net/csl.html>

Just not sure how easy that it to program (in JS, or Cocoa, etc.) ...

Bruce


Reply | Threaded
Open this post in threaded view
|

Re: GUI mockup

Johan Kool
In reply to this post by Bruce D'Arcus-3
Op 4-okt-2005, om 20:38 heeft Bruce D'Arcus het volgende geschreven:

> Johan Kool wrote:
>
>>> One thing of note is how you'd handle the layout nesting.  For  
>>> example, your "Author" field should be:
>>>
>>> creator
>>>    name
>>>    role
>> Something like this?
>
> No, because the names and role are nested.  One finds a similar  
> thing with the origin field, in order to get (New York: ABC Books).
Then it'll have to be a similar thing as I did with the container.

>
>> I hope there can not be a container within a container? I can't  
>> imagine any journal wanting to have such a reference in its articles!
>
> You certainly could for books: chapter, book, series.
>
> I ask about this because I've considered whether it might make  
> sense to reconsider this.  There are definite advantages to this  
> approach from a processing standpoint, because it makes it easy to  
> handle punctuation. Going to a flat model would make some things  
> more difficult. But it does become more tricky from a GUI  
> perspective to keep it nested.
It ain't pretty, but it's possible to program something like this:


It are things like that where I think that creating a GUI for CSL is  
silly. Most people will use a predefined one anyway... is there a  
minimum/maximum number of nestings needed for container?

Johan

pastedGraphic.png (67K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GUI mockup

Johan Kool
In reply to this post by Bruce D'Arcus-3
> Oh, this page has a mockup I did in HTML of the nesting:
>
> <http://xbiblio.sourceforge.net/csl.html>

The problem with your implementation is that I can only see the names  
of the deepest nested items. It's important to show it, otherwise it  
can get very confusing. I did another little mockup. Basically the  
same, but more inspired by NSTokenField. It should handle nesting  
quite nicely, as I made sure that Name within Creator is of the same  
height. Otherwise you'll get very odd things with big heights when  
using deeply nested structures.

The arrow indicates that there are actions to be performed on the  
item, such as adding other things and setting the fonts. It's  
important to have shortcuts here, as it otherwise can get a tedious  
job to work it all with the mouse. The label "Creator" "Name" etc.  
should reflect the font settings. The label (and any non-used area,  
should be used for dragging and rearranging of the items.

The biggest drawback is that the amount of coding needed to create  
such widget.



Johan

pastedGraphic.png (57K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GUI mockup

Bruce D'Arcus-3
Nice!

On 10/4/05, Johan Kool <[hidden email]> wrote:

> The biggest drawback is that the amount of coding needed to create
> such widget.

And is that because of the nesting, or just because it's a
non-standard widget that's doing a fair bit of work?

I had pinged a guy working on some magic javascript stuff, including
drag-and-dropable lists.  Maybe I should see what he thinks about it
WRT to JS, as he wanted to implement the hierarchcal dynamic lists
this would need?

The problem with the flat approach is you need some funky way to then
artifically (from an XML perspective) link content.  I always hated
the way Endnote handled that with it's weird syntax.

Bruce


Reply | Threaded
Open this post in threaded view
|

Re: GUI mockup

Johan Kool
Op 4-okt-2005, om 23:08 heeft Bruce D'Arcus het volgende geschreven:

> Nice!
>
> On 10/4/05, Johan Kool <[hidden email]> wrote:
>
>> The biggest drawback is that the amount of coding needed to create
>> such widget.
>
> And is that because of the nesting, or just because it's a
> non-standard widget that's doing a fair bit of work?

A quick look at the NSTokenField documentation makes me believe that  
it should be possible to subclass it into something like we have in  
mind. It's not the nesting that's the problem, it is very possible to  
put a view in a view in a view. So the good news is that NSTokenField  
seems to be a good starting point. Might our requirements proof to be  
more than that, then it's going to be a lot of work to implement the  
whole control.

I'll fiddle around a bit with this NSTokenField idea.

> I had pinged a guy working on some magic javascript stuff, including
> drag-and-dropable lists.  Maybe I should see what he thinks about it
> WRT to JS, as he wanted to implement the hierarchcal dynamic lists
> this would need?

My JS is very limited. Not much more than copy-pasting interesting  
things together. But my guess would be that creating such a control  
in html and javascript (I think it should be called AJAX?) is very  
well possible. He probably can do it. I should be able to do the  
Cocoa one, I can't do the JS one.

> The problem with the flat approach is you need some funky way to then
> artifically (from an XML perspective) link content.  I always hated
> the way Endnote handled that with it's weird syntax.

Endnote gets so much love from you!! ;-)

Johan



12