June 2005 - Development - lists.drupal.org

[drupal-devel] [bug] Drupal.js causes error in IE5
by Thox 01 Jun '05

01 Jun '05

Issue status update for http://drupal.org/node/24068 Project: Drupal Version: 4.6.0 Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Thox Updated by: Thox Status: patch Attachment: http://drupal.org/files/issues/drupal.js_1.patch (630 bytes) Drupal.js causes an "undefined is undefined on line 6" error in IE5. Don't you just love M$ error messages? Attached patch adds IE5 compatibility. Thox

1 0

[drupal-devel] Informal CivicSpace Meetup in Boston
by Chris Messina 01 Jun '05

01 Jun '05

All, I'll be traveling to NH and Boston from June 10 - 16 and thought that I might stage a small CivicSpace/Drupal community meetup. Since it would only be me representing CivicSpace, I imagine that it would be smaller than the recent NY CivicSpace meetup. Still, I'm hoping that folks like Morbus Iff, Moshe Weitzman, the Downhill Battle guys, Seth Cohn, Erik Hopp and others from the area might be able to attend (Aaron? Adam? Care to truck down from NY?). I'm looking into a couple options for space -- the Berkmann Center at Harvard is looking possible as well as another space being arranged by Rich Cowan. If anyone else has any ideas, please share! I'd also like to know if anyone has any specific topics they'd like to address or work on while I'm around. I figure more than anything my visit and staging of the meetup can serve as a catalyst for bringing some CS/Drupal folks together. Thus I'm pretty open to using our time for whatever folks want to focus on. Chris

4 4

[drupal-devel] [bug] Throttle, extra ')'
by Robin Monks 01 Jun '05

01 Jun '05

Issue status update for http://drupal.org/node/24057 Project: Drupal Version: 4.6.0 Component: throttle.module Category: bug reports -Priority: normal +Priority: critical -Assigned to: Anonymous +Assigned to: Robin Monks Reported by: pz Updated by: Robin Monks -Status: active +Status: patch Attachment: http://drupal.org/files/issues/throttle.module.extra_par.patch (721 bytes) Here it is in patch form. Robin Robin Monks Previous comments: ------------------------------------------------------------------------ June 1, 2005 - 08:46 : pz Commit #16445 adds an extra ')' to line 80, $message = format_plural($guests, '1 guest accessing site; throttle enabled.', '%count guests accessing site; throttle enabled.'));

1 0

[drupal-devel] [feature] book_print() should output correct HTML header and use CSS
by puregin 01 Jun '05

01 Jun '05

Issue status update for http://drupal.org/node/1899 Project: Drupal Version: cvs Component: book.module Category: feature requests Priority: normal Assigned to: al Reported by: kika Updated by: puregin -Status: active +Status: patch Please see the patch for http://drupal.org/node/1482, which fixes this, by producing a full DocType declaration for XHTML, an HTML element with namespace declaration, and a content-type hint for UTF-8 charset. puregin Previous comments: ------------------------------------------------------------------------ June 9, 2003 - 15:15 : kika As the subject says. CSS to be linked should be /misc/print.css ------------------------------------------------------------------------ June 10, 2003 - 17:31 : al I'll clean this up while I'm about it. ------------------------------------------------------------------------ May 5, 2005 - 00:25 : puregin The current CVS version still produces only <html> as a root element of the document. Is this good enough?

1 0

[drupal-devel] [bug] Book title formatting the same for all levels of the book
by puregin 01 Jun '05

01 Jun '05

Issue status update for http://drupal.org/node/8049 Project: Drupal Version: cvs Component: book.module Category: bug reports Priority: normal Assigned to: killes(a)www.drop.org Reported by: joel_guesclin Updated by: puregin -Status: active +Status: patch This issue is fixed with the patch for http://drupal.org/node/1482, together with the print.css stylesheet patch provided in http://drupal.org/node/1898. puregin Previous comments: ------------------------------------------------------------------------ May 25, 2004 - 09:34 : joel_guesclin When I ask for a "printer-friendly version" of a book, all the titles come out looking the same, they are marked: h1 id="3" name="3" class="book-h1" When I look at the code for function "book_print" in the book.module, it looks as if there is a variable which is supposed to change depending on the depth in the book - the variable is called $depth. But as far as I can see it is defined as "1" and never changes. I can't find this marked as a bug, but it seems to me to be one. Excuse me if I have missed something. ------------------------------------------------------------------------ June 1, 2004 - 07:48 : joel_guesclin Here is a solution for this which seems to work: In functions book_print and book_print_recurse change the line: <?php $output .= "<h1 id=\"$node->nid\" name=\"$node->nid\" class=\"book-h$depth\">$node->title</h1>"; ?> so that it looks like this: <?php $output .= "<h$depth id=\"$node->nid\" name=\"$node->nid\" >$node->title</h$depth>"; ?> This gets rid of the class book-h1 which is not referenced in the print.css Then, in book_print make sure that the call to book_print_recurse shows: <?php $output .= book_print_recurse($id, $depth + 1); ?> Correct the definition of book_print_recurse to read: <?php function book_print_recurse($parent = "", $depth) { ?> Then you might want to play with the misc/print.css but I'm still having trouble understanding that. ------------------------------------------------------------------------ June 2, 2004 - 17:04 : moshe weitzman I can confirm that book.module is still outputting this non-ideal markup in HEAD. See book_print() ------------------------------------------------------------------------ October 8, 2004 - 14:38 : killes(a)www.drop.org Here is a patch that also takes care to no increase the depth over 6. The patch is untested but run through php -l. ------------------------------------------------------------------------ October 8, 2004 - 14:39 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/book_16.patch (1.67 KB) And here'S the patch... ------------------------------------------------------------------------ October 8, 2004 - 23:32 : Dries Not sure. A lot of book pages use h2 and h3 headers. ------------------------------------------------------------------------ October 9, 2004 - 10:22 : killes(a)www.drop.org IMNSHO they shouldn't. If you need substructures that qualify for h2 or h3 you should create subpages. Long pages aren't good to read on a screen. ------------------------------------------------------------------------ October 9, 2004 - 11:07 : Steven The book has to do a trade-off between the amount of clicks required to reach a topic and the amount of information on a page. There are many cases where h2 and h3 usage is valid. ------------------------------------------------------------------------ October 9, 2004 - 11:09 : Steven The book has to do a trade-off between the amount of clicks required to reach a topic and the amount of information on a page. There are many cases where h2 and h3 usage is valid. ------------------------------------------------------------------------ October 13, 2004 - 19:59 : Steven It should be possible to check which h's are used in a book page, and renumber them. Eg. if we are at level 3 in the book (<h3>), and the body uses <h2> and <h4>, we renumber those to <h4> and <h5>. ------------------------------------------------------------------------ October 17, 2004 - 12:17 : Dries Not going to commit this patch as is. It needs more thought. ------------------------------------------------------------------------ February 15, 2005 - 18:59 : clairem I'm glad to see that this patch is still marked as active, beacuse I want to suggest an alternative way of developing the same idea -- which at its core is about differentiating the difft levels of a book. First I should say that I agree with Steven's point that use of h2 and h3 can sometimes be valid in book pages, and I would add that possibly h4 h5 and h6 may be valid as well. We may all have our preferences, but site maintainers juggling their options may make their choices in circumstances which developers have not envisaged. Renumbering h/n/ tags could break pages: a h3 tag in a book page at depth4 would be renumbered as h7. Not good. So, instead of renumbering the headings, why not use the depth to wrap each book page in a div with an appropriate class, like this: <div class="depth0"> <h1>Animals</h1> wibble </div> <div class="depth1"> <h1>Mammals</h1> flurble </div> <div class="depth2"> <h1>Primates</h1> blurble </div> etc ... Then print.css could set the indentation for depth, as follows: .depth0 {padding-left: 0); .depth 1 {padding-left: 1em;} etc... Site managers could modify print.css to suit their needs, without ever having to tweak the Drupal code ... and without their h/n/ tags being modified ------------------------------------------------------------------------ May 5, 2005 - 01:03 : puregin Please see also the related discussion on http://drupal.org/node/1898 I'm completely in support of clairem's idea to wrap sections in <div> tags. However, at the risk of repeating myself to excess - any use of H1, H2, ... H6 inside of a book page is a sign of something not right. These should *never* appear. Having them present implies: * It will be impossible for others to add or re-arrange sections unless they have edit permissions for a page. * Individual authors can hijack the apparent (presentational) structure of a book by arbitrarily beginning new chapters, for example * There is no guarantee of coherence (hierarchy) in the presentation of the book * The structure of the document is not accessible to the navigational elements presented by Drupal - sections will disappear from the book navigation view, forward/up/next links, etc. If you feel the urge to include them in your book page, one or more of the following is probably true: * Your page is too long. If readers need to scroll through a long page, they will probably need the navigational clues that headings provide - but they will in all cases be better served by having the page divided into true subsections via child nodes. * You are trying to present some kind of list. Try using <dl>, <dt>, <dd> instead * You are trying to achieve visual impact. Visual impact is OK, though it's often not done well. If you must, do it with style (pun intended) * Your page is essentially just a container for subsections - try pushing content up into the parent or down into children and eliminate the page entirely. ------------------------------------------------------------------------ May 5, 2005 - 01:12 : puregin Please see also the related discussion on http://drupal.org/node/1898 I'm completely in support of clairem's idea to wrap sections in <div> tags. However, at the risk of repeating myself to excess - any use of H1, H2, ... H6 inside of a book page is a sign of something not right. These should *never* appear. Having them present implies: * It will be impossible for others to add or re-arrange sections unless they have edit permissions for a page. * Individual authors can hijack the apparent (presentational) structure of a book by arbitrarily beginning new chapters, for example * There is no guarantee of coherence (hierarchy) in the presentation of the book * The structure of the document is not accessible to the navigational elements presented by Drupal - sections will disappear from the book navigation view, forward/up/next links, etc. If you feel the urge to include them in your book page, one or more of the following is probably true: * Your page is too long. If readers need to scroll through a long page, they will probably need the navigational clues that headings provide - but they will in all cases be better served by having the page divided into true subsections via child nodes. * You are trying to present some kind of list. Try using <dl>, <dt>, <dd> instead * You are trying to achieve visual impact. Visual impact is OK, though it's often not done well. If you must, do it with style (pun intended) * Your page is essentially just a container for subsections - try pushing content up into the parent or down into children and eliminate the page entirely.

1 0

[drupal-devel] [bug] Strange markup in book render functions
by puregin 01 Jun '05

01 Jun '05

Issue status update for http://drupal.org/node/1898 Project: Drupal Version: cvs Component: book.module Category: bug reports Priority: critical Assigned to: puregin Reported by: kika Updated by: puregin Status: patch This patch is subsumed in my patch for issue http://drupal.org/project/comments/add/1482, which provides for XML export of books. Note that the patch for print.css in this issue still applies with the new patch. puregin Previous comments: ------------------------------------------------------------------------ June 9, 2003 - 15:06 : kika Snippet from book_render(): $output .= "<dt>". l($node->title, "node/view/$node->nid") ."</dt><dd>". book_body($node) ."<br /><br /></dd>"; Is using definition list here is really correct? This should be replaced with appropiate div's or even better, funnel through theme() Same goes for the function book_print(): $output .= "$node->title"; if ($node->body) { $output .= "<ul>". book_body($node) ."</ul>"; } Why wrap body inside <ul>? ------------------------------------------------------------------------ June 10, 2003 - 17:31 : al Yeah, it's all nasty. I patched this ages ago, but no one seemed interested. The patch now won't apply due to all the changes since then. I'm on this - expect a new patch to hit my sandbox shortly. ------------------------------------------------------------------------ June 10, 2003 - 23:03 : ax please remove the superfluous <ul>s and <li> [1], too. to solve the problem of invalid nested <hx> tags, maybe we should change <h$depth> to <h1 class="book-h$depth">? this way, we could use <h2> - <h6> in book pages. alternatively, we should only use <h5> and <h6> in book pages - we shouldn't have nestings deeper than 4 in printed books, then. additionally, i think it would be a good idea to add id's to all book headings so they can be jumped to via fragment identifiers (url#fragment-identifier). i often wish this would be possible when referencing the last paragraph of a long page of documentation ... these id's should be of the form <hx id="foo" name="foo"> [2], with foo probably being the node-id of the single book page. adding id's to headings would also be a good idea for headings / sections in single book nodes. for example, it would be nice if i could link to list point 10 in the drupal installation instructions [3] via something like url#10. these id's had to be added manually. the question is: how can these id's be named to be unique within a /printed/ book? probably <node_id>_<section_id> ... [1] [ [drupal-devel] Drupal handbook formatting and heading tags | http://lists.drupal.org/pipermail/drupal-devel/2003-June/025860.html ] [2] [ XHTML Spec, HTML Compatibility Guidelines, Fragment Identifiers | http://www.w3.org/TR/xhtml1/#C_8 ] [3] http://drupal.org/node/view/260 ------------------------------------------------------------------------ June 15, 2003 - 07:23 : al Fixed in latest CVS. Uses all of Ax's suggestions: - <h1 class="depthX"> - Fixed to use CSS rather than tables. - Changes link at top to standard "breadcrumb" style, rather than hierarchy in tree view. - Removes odd and superfluous <ul> tags and the like. - Makes printed docs have proper <html> and <body> wrapping, etc. ------------------------------------------------------------------------ May 5, 2005 - 00:20 : puregin I'm re-opening this, because the problem persists in CVS. 1) The current CVS version (1.288.2.4) of book module still wraps $node->body in an <ul> element in book_print_recurse(). This produces non-conformant HTML. I'm not sure why this was done in the first place - I'm guessing someone wanted to insulate from having bad markup in a book page throw off the enclosing page. Getting rid of the offending UL tags is a one-line solution, but what is the right thing to do here? I'd like to see something very structural - wrapping the /entire/ output (including the generated sectional header) of the book_print_recurse() wrapped in a <div> element. This will properly nest true structural sections, making the structure accessible to applications via DOM. It will also make it easier to use XSLT, for example, to transform into various XML based export formats, for example. Any reason not to do so? Also... when we get the 'printer-friendly' version of a page, the subtree rooted at that page is returned, and the root page is marked up with a class="book-h1". Is there any reason why we don't compute the depth of the root page, and use that to generate the "in-place" header? In other words, if a section is "book-h3" relative to the top-level book, shouldn't it be "book-h3" whenever it is viewed? In this case, we could apply the same principal to generating the <div> tags around each section. ------------------------------------------------------------------------ May 5, 2005 - 15:58 : puregin Attachment: http://drupal.org/files/issues/book_printer_friendly_div.patch (1.57 KB) I am attaching a patch which fixes improper printer-friendly output, as discussed. The patch fixes book_print and book_print_recurse() to insert a <div> start tag before emitting the header, and to close this after subsections have been recursively generated. The <div> tag has an id attribute of the form id="sect-123", where the node's nid is 123, and a class attribute of form class="sect/n/" where the depth of the section is /n/. I'm marking this issue as critical, since the present HTML output plays havoc with any attempts at sane PDF generation. I will address the issue of where printer-friendly subsections should be 'rooted' in a follow-up. Djun ------------------------------------------------------------------------ May 6, 2005 - 01:53 : Dries Let's not abbreviate 'section' to 'sect'. Also, we use '-' to separate words in CSS names. - If the section ID uses the node ID, maybe we should use 'node-' instead of 'sect-'? - If the class uses depth, maybe we should use 'depth-' instead of 'sect'? The same is true for your other patch where you suggest to use 'n'. Better to make that 'node-'. (Feel free to merge both patches.) Looks like the book.module generates a _lot_ of CSS IDs/classes. If the introduction of these new IDs/classes allows us to remove some of the existing IDs/classes, please do. ------------------------------------------------------------------------ May 6, 2005 - 21:26 : Steven Here's my idea.. why not use regular h tags for the book structure, and renumber the header tags in the content, starting one level after the current book depth? Here's a function which does this: <?php function fix_up_headers($text, $level = 1) { // Find all header tags that are used (if any) if (preg_match_all('/<h[0-9]+/i', $text, $tags) == 0) { return $text; } // Discard duplicates and sort them by number $tags = array_unique(array_map('strtolower', $tags[0])); natsort($tags); // Renumber them and replace them $i = $level; foreach ($tags as $tag) { $from[] = '@'. preg_quote($tag) .'(?![0-9])@i'; $from[] = '@'. preg_quote(str_replace('<', '</', $tag)) .'(?![0-9])@i'; $to[] = '<h'. $i; $to[] = '</h'. $i; $i++; } $text = preg_replace($from, $to, $text); // Change level 7 headers and higher to divs. return preg_replace(array('!<h([7-9]|[1-9][0-9]+)!i', '!</h([7-9]|[1-9][0-9]+)!i'), array('<div class="header-\1"', '</div'), $text); } ?> That way you can use header tags safely in the content (which is useful in the context of a single page) without messing up the book output. ------------------------------------------------------------------------ May 7, 2005 - 00:50 : puregin Attachment: http://drupal.org/files/issues/02_book_printer_friendly_div.patch (1.78 KB) The attached patch changes the div id to the form 'node-123'. I was concerned that a document fragment might be created with both a book section and a non-book section from the same node, leading to non-unique id's, but at this point it seems like an unlikely scenario. I've changed 'class=sect1' to 'class=section-1'. I was trying to be lazy and use the DocBook section name convention to make XSLT conversion a little easier, but it's really not saving any effort, in the end, and this is clearer. I think 'section' rather than 'depth' is appropriate - it describes what the role of the div element is. I've closed the other issue regarding id's in header elements, because I've replaced the whole 'class="book-hx"' business in headers with 'class="book-header"'. Since the level can now be selected by context with respect to the enclosing div, separate classes for headers are not required. That is, we can style with CSS like the following: .section-1 h1.book-header { font-weight: bold; font-size: 2.2em; } .section-2 h1.book-header { font-size: 2em; } .section-1 p { text-align: justified; } .section-3 p { margin-left: 3em; margin-right: 3em; } Note that the section-2 h1 will be bold, since the section-2 div is nested within the section-1 div. Also, all paragraphs regardless of section will be justified; and section-3 paragraphs will be indented left and right. Because we can style /everything/ by section, not just headers, and because the styling specifications respect the sectional hierarchy, it's possible to create very elegant and sophisticated book pages with very little CSS. Even I can do it! :) I'm definitely *not* a designer, but I've played around a bit with this - have a look at http://www.puregin.org/book/print/129 for an example. I will attach patches for misc/print.css and misc/drupal.css separately. I don't understand why, but the present version (cvs) of these files has all of the h1.book-hx selectors in drupal.css - the printer-friendly page actually looks at print.css. Am I missing something? For the record, this approach seems to have been suggested by clairem in http://drupal.org/node/8049 where I have a little rant about headings in book pages. Twice :) Djun ------------------------------------------------------------------------ May 7, 2005 - 01:10 : puregin Steven - that's a neat idea, and very clever, clean code! But it still doesn't catch problems such as, for example, an h5 inside of an h1 section with no intervening h2..h4 headers, or? I'm inclined to be a bit suspicious of the approach, though - I rather think it's 'doing magic behind the user's back'. If people are going to insist on putting headings inside of pages, it should be possible. And it would be odd for users to discover that what they typed isn't what they get. ------------------------------------------------------------------------ May 7, 2005 - 01:32 : puregin Attachment: http://drupal.org/files/issues/print_css_div.patch (1.36 KB) Here's the patch for print.css. There's a couple of commented-out lines - these show how to make section headings 'run in' as part of the following paragraph (or other inline element). I am assuming that print.css is supposed to be something of an example that people would use to experiment with? Please feel free to improve this in any way - as I said, I'm far from being a graphic designer, and I'm also not really sure what the intention of this file is. ------------------------------------------------------------------------ May 7, 2005 - 11:40 : Steven Puregin: nope, the code correctly handles missing h numbers. If the book page only uses h2, then that will be the first new level. If it uses h2 and h4, and it is inside a 3rd level book page for example (whose title would be h3), they they get renumbered to respectively h4 and h5 (no missing number). >From a semantic point of view it is crazy not to use h# for book titles. ------------------------------------------------------------------------ May 7, 2005 - 11:44 : Steven A bit more verbose: I think the overwhelming majority of users browse a book on the site itself. Within a single page, there is a h1 tag for the page title. So it makes sense for a writer to use h2, h3, etc inside a single page. This is semantically valid HTML. On the other hand, the print output places the content in a whole new context. I would expect the book module to take whatever steps necessary 'behind the user's back' to ensure it displays correctly. ------------------------------------------------------------------------ May 7, 2005 - 13:43 : puregin Sorry, I replied to the last post on the list - I'll include the post here for the record, and expand a little. Steven, I think that the issue you're addressing is actually a different one than I am trying to fix in my patch, which addresses how sections are wrapped. My patch would still allow users to write headers in their book pages - it would then be up to post-processing - or something like your approach - to deal with how embedded headers are dealt with. Perhaps we should take up your suggestion in another of the book.module issues dealing with the sequences of headers? How about http://drupal.org/node/8049, or http://drupal.org/node/4118? With respect to your suggestion - I understand now that you're proposing to apply the re-writing only to the printer-friendly output. I'm conflicted about this idea - on the one hand, the output which it produces is clearly an improvement over the present output. On the other hand, it changes what the user types to make it 'right' - I guess this is in the long tradition of HTML being interpreted very forgivingly by web-browsers and other applications. On the balance, I support your idea - I guess it's in the spirit of 'make things easier for the user'. With respect to the actual code - I don't think it will handle the case where h2, h3, and h4 are all used in the text, but the sequence h2, h4 occurs. To put it another way, the problem of checking whether headers are in a legal sequence is context sensitive, while a regular-expression search and replace (even if the replacement sequence remaps the targets) is context-free. When I say legal sequence, I mean legal in terms of book hierarchy, not in terms of the XHTML definition, which doesn't address hierarchy, because headers are titles, not sectional elements. SGML/XML publishing DTDs define such things via inclusion/exclusion on true sectional elements) The case I described is, admittedly, a relatively infrequent occurrence, and the general solution would be way to difficult to deal with - it would involve constructing and manipulating a DOM, or something along those lines. Ugh! Djun ------------------------------------------------------------------------ May 18, 2005 - 10:24 : cel4145 The Drupal doc team is very interested in being able to import/export book content. I'm sure that others would be interested in it, too. Djun has indicated that this patch is a good step toward having that functionality So +1 if the developers can help him to get this patch so that it can be implemented.

1 0

[drupal-devel] [feature] export book as xml for formatting
by puregin 01 Jun '05

01 Jun '05

Issue status update for http://drupal.org/node/1482 Project: Drupal Version: cvs Component: book.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: BenEng Updated by: puregin -Status: active +Status: patch Attachment: http://drupal.org/files/issues/xml-export.patch (14.06 KB) This patch enables export of books as XML documents. The XML is DocBook "at the level of structure", but node contents are wrapped as CDATA, since we can't be sure that the contents are valid XML. Several other bugs/feature requests are also addressed with this patch: - Fixes bugs http://drupal.org/node/1898 http://drupal.org/node/1482 http://drupal.org/node/8049 http://drupal.org/node/1899 Should go a long way towards implementing feature request http://drupal.org/node/2062 It should also be easy to extend this to produce OPML, for example. - Adds about 170 lines, of which more than 100 are comments - Added doxygen comments - Made doxygen comment format consistent; fixed minor grammatical slips - A proper Doctype and more informative HTML element is generated for printer-friendly HTML output. - Refactored book_print() to use book_recurse(). - Refactored book_recurse(). Applies 'visitor' callback functions to nodes during weight/title order tree-traversal. The parameterized visitor callbacks can be used to generate different kinds of output. There are many other kinds of operations on books which can be implemented by writing a pre-node/post-node pair of callback functions: word-count/ statistics gathering, comparison, copying, search and replace... - Introduced book_export() which uses book_recurse() to generate DocBook-like XML to export book contents in a structured form. An md5 hash is computed for each node to help import code to decide if a node needs to be updated or not. puregin Previous comments: ------------------------------------------------------------------------ April 5, 2003 - 14:38 : BenEng Export an entire collaborative book to xml (docbook) so that it can be formatted using xslt (e.g., to rtf or pdf) and printed. It would also be nice to be able to perform the reverse. That is to import a collaborative book from an xml (docbook) file that is uploaded. ------------------------------------------------------------------------ June 2, 2004 - 17:10 : moshe weitzman can someone suggest an xml schema for this? i think we need a general xml schema for nodes. after that, this becomes a simple matter of nesting node elements (I think) ------------------------------------------------------------------------ February 1, 2005 - 02:42 : Teto Hi, Is there any news about a such feature ? All i've found about a docbook schema is here : http://docbook.sourceforge.net/projects/schema/ It seems there isn't much in the docbook cvs about that. Teto. ------------------------------------------------------------------------ May 14, 2005 - 02:11 : puregin Here's a list of the Book publishing DTDs I know about: NameNotesRef ISO 12083:1998//DTD Book//EN - this includes ISO 12093:1993//DTD Mathematics//EN Committee standard - very general. Used e.g. by University of California Press. www.xmlxperts.com/bookdtd.htm [1] DocBook Applications - widely used by Computer book publishers, e.g. O'Reilly. Good support. docbook.org [2] TEI/TEI-Lite Applications - scholarly/historical/literary documents www.tei-c.org [3] MIL-STD-38784 (CALS) Applications - Military/Govt/Enterprise publishing http://xml.coverpages.org/mil-std-38784-a1-dtd.txt [4] I'd highly recommend DocBook as a useable, technically focused, XML DTD with strong toolset support. [1] http://www.xmlxperts.com/bookdtd.htm [2] http://docbook.org [3] http://www.tei-c.org/ [4] http://xml.coverpages.org/mil-std-38784-a1-dtd.txt ------------------------------------------------------------------------ May 18, 2005 - 01:37 : puregin I'd suggest we start with something very simple. The patch which I submitted for http://drupal.org/node/1898 wraps each node in <div> tags, with a level, and a node id attribute, for printer friendly output. We can't rely in general on the contents of a node being XHTML, even if we force output through an XHTML validator such as tidy. So our best bet is to encode the entire contents of a node as CDATA. This gives us hierarchy, and encapsulated contents (of any kind - later this could also be other kinds of data or markup) This output will be valid XML, with a pretty simple DTD. It is easy to take such a file and write simple XSLT based scripts on the the client side to explode this file into a directory tree of HTML, a single HTML file, or many other formats. Importing is trickier. It's relatively easy to import an exported file, and update the nodes of the book according to the hierarchy defined by the sectional <div> elements. Importing needs to take care of structure which has changed - child nodes added, deleted, or moved. It would also be nice to have some client-side scripts to import other formats into this nested sectional <div> based format - for example, to take a directory tree of HTML fragments, and make this into an importable file.

1 0

[drupal-devel] drupal in reboot?
by Kristjan Jansen 01 Jun '05

01 Jun '05

Hi, I am attending http://reboot.dk/ this year (10-11 June), is anybody from Drupal crew plans to be there?

1 0

Re: [drupal-devel] [contributions:weitzman] /modules/devel pgprefix.sh
by Dries Buytaert 01 Jun '05

01 Jun '05

On 01 Jun 2005, at 05:29, drupal-cvs(a)drupal.org wrote: > User: weitzman Branch: HEAD Date: Wed, 01 Jun 2005 03:29:27 > +0000 > > Added files: > /modules/devel pgprefix.sh > > Log message: > #23340 add a pgsql prefix script The prefix.sh script in HEAD (and DRUPAL-4-6, not Drupal 4.6.0) should work with PostgreSQL. -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] [bug] Enable/disable user picture option should not exist in two places
by Steven 01 Jun '05

01 Jun '05

Issue status update for http://drupal.org/node/23310 Project: Drupal Version: 4.6.0 Component: user.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: factoryjoe Updated by: Steven Status: patch Attachment: http://drupal.org/files/issues/picture_0.patch (1.22 KB) Ah, it seems we prefer to disable the toggles rather than hide them. It is probably for the best (I've always read you should disable options if they can be enabled by the user in this session). I had to generalize the check for search.module a bit, the code is cleaner now. Steven Previous comments: ------------------------------------------------------------------------ May 21, 2005 - 01:47 : factoryjoe Because you can enable/disable user pictures in the PHPTemplate config pages, that option should not exist under admin/users. And if PHPTemplate shouldn't handle this option, it should be removed from PHPTemplate's config screens. This option should be set in one place, and one place only. ------------------------------------------------------------------------ June 1, 2005 - 06:47 : Steven Attachment: http://drupal.org/files/issues/picture.patch (1.07 KB) I disagree... the option in admin/users controls whether users can upload a picture. This image is always displayed in their profile and this is a user.module feature. The PHPTemplate options on the other hand control whether pictures are displayed next to nodes resp. comments. This is a theme feature. The two are different and complement each other. Sometimes you may want users to have pictures, but not have them displayed next to each post. In that case you could even let users upload larger pictures of themselves as they don't need to fit snugly next to text. However you are partially right: it does not make sense to show the PHPTemplate options if user pictures are not allowed, so we should only make them appear in the right situation. I've attached a patch for this.

1 0