Re: [docbook-apps] Apostrophe in docbook document
Hi,
Ron Catterall wrote:
Could somebody tell me which is the correct symbol to use for apostrophe.
The HTML special characters entity set has apos #x27 where apos
presumably stands for apostrophe - this is the straight up single quote
mark which XML defines and uses for special purposes.
It’s advised not to use it for apostrophe. It should be used only in
programming languages, XML, etc. So, as you said, for special purposes.
The Shorter Oxford English Dictionary on-line tells me:
The omission of one or more letters in a word.
A sign (') used to indicate the omission of one or more letters or
numerals (as in can't, o'er, 'cello; spirit of '76 (i.e. 1776)), or in
marking the possessive case (man's, boys').
So SOED appears to use apos. Do they know, or just confused? Or could
it be a UK/US difference?
(I've always used the keyboard ' for XML use and apos when I want the
apostrophe in text.)
You must be one of the very rare ones!
Wikipedia tells me:
The apostrophe is different from the closing single quotation mark
(usually rendered identically but serving a quite different purpose),
and from the similar-looking prime (which is used to indicate
measurement in feet or arcminutes, and for various mathematical purposes).
So Wiki tells me use rsquo #x2019 (#8217) which looks like an
apostrophe, and not to use apos or prime (#x2032)
but also:
The prime symbol should not be confused with the apostrophe, single
quotation mark, acute accent or grave accent.
Not sure you will be pleased by this, but to my knowledge Unicode
defines only one code point for both the apostrophe and the right single
quotation mark (U+2019). There are different code points for prime
(U+2032) and acute accent (U+00B4), though. Strictly speaking, I suppose
that there should be two different code points for apostrophe and right
single quotation mark, that would be rendered using the same glyph by
most fonts. I don’t know if this is an oversight from the Unicode
Standard committee or if it was deliberately done so because that would
otherwise be splitting hair too much.
Quote from the Unicode Standard, version 5.2:
‘Punctuation Apostrophe. U+2019 right single quotation mark is
preferred where the character is to represent a punctuation mark, as
for contractions: “We’ve been here before.” In this latter case,
U+2019 is also referred to as a punctuation apostrophe.’
And also:
‘When text is set, U+2019 right single quotation mark is preferred
as apostrophe, but only U+0027 is present on keyboards. Word
processors commonly offer a facility for automatically converting
the U+0027 apostrophe to a contextually selected curly quotation
glyph.’
Vincent
Jacques Foucry wrote:
On 25 janv. 2010, at 17:30, Mathieu Malaterre wrote:
Hello,
#3 is the fastest to type. #2 and #4 are ugly to read when editing
the .xml file using text file. How about solution #1
In my source document I use the single quote (#4). In my custom
stylesheet I change them by the curly quote (#1).
xsl:param name=singlequote
xsl:text'/xsl:text
/xsl:param
xsl:param name=curlyquote
xsl:text’/xsl:text
/xsl:param
xsl:template match=d:para/text() | d:title/text()
xsl:value-of select=translate(.,$singlequote,$curlyquote)/
/xsl:template
I do not change for computeroutput or litteral tags.
Jacques
-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] inlinemediaobject + caption for epubs?
Hi, I'm trying to create xhtml/epub content and trying to use images which are right-aligned and floating but have captions. I don't want images to interrupt the flow of the page when it's in epub. Instead I want text to wrap around a right-aligned image. It looks like inlinemedia is the best element for that; however, by default inlinemedia doesn't allow captions -- only textobjects which don't render in chunked html output (only as alt text). I need the equivalent of captions for inlinemedia elements. Is there a way to override that so that textobjects are visible? The problem here is that mediaobjects are block elements (which make sense for html and fo output, but not for epub). When dealing with smaller sized screens, using the extra space to separate an image block element is wasteful and inefficient. Any ideas for how to solve this problem? Robert Nagle Houston, Texas http://www.imaginaryplanet.net/weblogs/idiotprogrammer/ - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] inlinemediaobject + caption for epubs?
On Tue, Jan 26, 2010 at 3:59 AM, Robert Nagle idiotprogram...@gmail.com wrote: I don't want images to interrupt the flow of the page when it's in epub. Instead I want text to wrap around a right-aligned image. OK, that sounds like presentation. It looks like inlinemedia is the best element for that; ...but that sounds like semantics. however, by default inlinemedia doesn't allow captions -- only textobjects which don't render in chunked html output (only as alt text). I need the equivalent of captions for inlinemedia elements. ...but inlinemedia elements are, by definition, untitled/captioned. A caption is an extended description of a mediaobject or figure or other formal or informal element. The problem here is that mediaobjects are block elements (which make sense for html and fo output, but not for epub). When dealing with smaller sized screens, using the extra space to separate an image block element is wasteful and inefficient. Any ideas for how to solve this problem? Why not solve the problem in the CSS in the ePub? You'll already need to be adding CSS customizations (for wrapping and alignment) to try to get the desired behavior (although a reading system may choose to ignore your requests), so adding more instructions to control the display behavior (block, inline, etc) would make sense. Keith - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] html2docbook: issue with h2/
Hi there, I'd like to know if anyone is using the script from the page: http://wiki.docbook.org/topic/Html2DocBook I tried on a very tidy example: $ cat input.xhtml !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; body h1Title1/h1 pbla 1/p h2Title2/h2 pbla 2/p /body /html Here is what I get as output: $ cat output.xml ?xml version=1.0? section titleTitle1/title parabla 1/para parabla 2/para /section The title in h2 element is lost during the conversion. Any idea on how to fix that ? Thanks, -- Mathieu - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Apostrophe in docbook document
On Tue, 26 Jan 2010 14:42:34 -0600, Ron Catterall r...@catterall.net wrote: Imagine a linguist wanting to search some text to count ... The problem of course is not a Docbook problem, it is in the UTF tables The problem is with neither, it is with the linguist :-). (I can say that, because I'm a linguist.) All seriousness aside, using corpora for linguistics requires more than looking for certain Unicode characters, which may not be used consistently anyway (and especially in a case like this, where the characters--if they were distinct Unicode characters--would doubtless be confused). Distinguishing between quotes and apostrophes requires some fairly complex methods. There are rules of thumb that often work, but they will break on certain cases. Corpora linguists become familiar with where these things break, and construct work-arounds accordingly, or hand-tag recalcitrant cases. If you really want an interesting problem, go for distinguishing among the uses of the ASCII period! Mike Maxwell - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Re: [docbook] DocBook and Google Summer of Code ?
Mid-december I sent a mail to this list, suggesting that DocBook applies to participate in Google's Summer of Code program. A couple of people followed up with interest and ideas, so I'd like to send out a little note with some details. Google just sent out this: http://groups.google.com/group/google-summer-of-code-discuss/browse_thread/thread/d839c0b02ac15b3f?pli=1 The most important bit is this: We will begin accepting application from would-be mentoring organizations beginning March 8th at approximately 19:00 UTC, with applications closing on March 12th at 23:00 UTC. I would like to suggest that, as a start, we collect project ideas on the wiki. (I was going to do that, then realized that the pages I looked at where marked immutable. May be I'm just lacking enough karma to edit them. Can someone help ? A new GSoCIdeas page would be a good start !) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Re: [docbook] ePub: Title page missing and ToC in spine?
[Back to DocBook-Apps] On Tue, Jan 26, 2010 at 2:00 PM, Boris Schäling bo...@highscore.de wrote: While this all works with the book I'm experimenting with I don't know if there are use cases where the predicates applied to the book node make sense? Simply removing them might have side effects? Setting root.is.a.chunk always to 1 might have side effects, too? But there is someone who wrote this code and should know? :-) Most of the XSLT for the ePub output was developed in a test-first style, so it's unlikely but possible that I just added code that has no impact. If you'd like to understand the impact of changes to the XSLT on a larger set of inputs, I'd suggest running the test suite and smoketests for the ePub output that are (briefly) described here: https://docbook.svn.sourceforge.net/svnroot/docbook/trunk/xsl/epub/bin/spec/README I've added the output of the test suite from my machine on the current SVN trunk to the end of this email to clarify what you should see. I'm also able to get 211 of the 224 smoketests (94%) to pass, which is normal. If the above helps clarify some of the design decisions and expose areas for fixes and improvements, I'd be delighted to see bug reports with test documents attached, failing test cases, and/or patches with new test cases fixes. That said, the continued refinement of the ePub stylesheets is not a high priority for me at this time[1], so I'm eager to help others make contributions to improve the quality of the code, documentation, and output. Regards, Keith 1. Although I won't rule out the idea that it could be again with the right motivation. http://threepress.org spec/epub_spec.rb DocBook::Epub - should be able to be created - should fail on a nonexistent file - should be able to render to a file - should create a file after rendering - should have the correct mimetype after rendering - should be valid .epub after rendering an article - should be valid .epub after rendering an article without sections - should be valid .epub after rendering a book - should be valid .epub after rendering a book even if it has one graphic - should be valid .epub after rendering a book even if it has many graphics - should be valid .epub after rendering a book even if it has many duplicated graphics - should report an empty file as invalid - should confirm that a valid .epub file is valid - should include at least one dc:identifier - should include an ISBN as URN for dc:identifier if an ISBN was in the metadata - should include an ISSN as URN for dc:identifier if an ISSN was in the metadata - should include an biblioid as a dc:identifier if an biblioid was in the metadata - should include a URN for a biblioid with @class attribute as a dc:identifier if an biblioid was in the metadata - should not include PDFs in rendered epub files as valid image inclusions - should include a CSS link in HTML files when a CSS file has been provided - should include CSS file in .epub when a CSS file has been provided - should include a reference in the OPF manifest to the provided CSS file - should include a reference in the OPF manifest to the embedded font - should include the embedded font file in the bundle - should be valid .epub after including more than one embedded font - should include one and only one h1 in each HTML file in rendered ePub files for books - should include one and only one h1 in each HTML file in rendered ePub files for books even if they do not have section markup - should include a TOC link in rendered epub files for books - should allow for the stylesheets to be overridden by a customization layer Finished in 64.169372 seconds 29 examples, 0 failures == spec/epub_realbook_spec.rb DocBook::Epub - should be able to render a valid .epub for the 'Real Book' test document - should include the large cover image in each rendered epub of a 'Real Book' test document like - should mark the HTML cover as not linear for the 'Real Book' test document - should use the cover image @id for the opf/me...@name='cover'] for the 'Real Book' test document - should reference the cover in the OPF guide for the 'Real Book' test document - should use the isbn as dc:identifier for the 'Real Book' test document - should use the copyright as dc:rights for the 'Real Book' test document - should use the publishername as dc:publisher for the 'Real Book' test document - should use the abstract as dc:description for the 'Real Book' test document - should use the date as dc:date for the 'Real Book' test document - should use the subjectset as dc:subject for the 'Real Book' test document Finished in 23.976278 seconds 11 examples, 0 failures == DocBook::Epub - should not include two itemrefs to the contents of parts in the OPF file - should preserve content from dedication elements - should use the correct mimetype for CSS files - should not include an XHTML DOCTYPE in the OPF file - should reference a cover in the OPF guide for a DocBook 5.0 test document - should allow pre elements
Re: [docbook-apps] Re: [docbook] DocBook and Google Summer of Code ?
Regarding the DocBook Wiki, it is currently broken. No one seems to have write access any more, including the main administrator Norm Walsh. He is working on fixing it, or perhaps recreating it if that does not work. Bob Stayton Sagehill Enterprises b...@sagehill.net - Original Message - From: Stefan Seefeld seef...@sympatico.ca To: docb...@lists.oasis-open.org; DocBook Apps Mailing List docbook-apps@lists.oasis-open.org Sent: Tuesday, January 26, 2010 4:47 PM Subject: [docbook-apps] Re: [docbook] DocBook and Google Summer of Code ? Mid-december I sent a mail to this list, suggesting that DocBook applies to participate in Google's Summer of Code program. A couple of people followed up with interest and ideas, so I'd like to send out a little note with some details. Google just sent out this: http://groups.google.com/group/google-summer-of-code-discuss/browse_thread/thread/d839c0b02ac15b3f?pli=1 The most important bit is this: We will begin accepting application from would-be mentoring organizations beginning March 8th at approximately 19:00 UTC, with applications closing on March 12th at 23:00 UTC. I would like to suggest that, as a start, we collect project ideas on the wiki. (I was going to do that, then realized that the pages I looked at where marked immutable. May be I'm just lacking enough karma to edit them. Can someone help ? A new GSoCIdeas page would be a good start !) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
