- BEGIN LOGGING AT Sat Feb 24 17:55:01 2007
Feb 24 17:55:01 * Now talking on #fedora-docs
Feb 24 17:55:01 * Topic for #fedora-docs is: Fedora Documentation Project -=- Discussions between writers, editors, translators, and developers about documentation -=- For end-user support, use #fedora -=- DocsProject-=- Interested in documentation? http://www.fedoraproject.org/wiki/DocsProject/NewWriters -=- Elections: http://fedoraproject.org/wiki/DocsProject/Policy/FDSCoElections -=- "I'm in ur docs correctin ur speling
Feb 24 17:55:01 * Topic for #fedora-docs set by quaid at Thu Feb 22 19:52:09 2007
Feb 24 17:55:05 <quaid> I want to discuss it with you and stickster in a few, let me get some coffee and oatmeal started :D
Feb 24 17:55:13 <jmbuser> Greetings and Salutations
Feb 24 17:55:35 <jmbuser> FOSDEM crowd there?
Feb 24 17:55:42 <couf> jmbuser: sure
Feb 24 17:55:54 <jmbuser> couf: hi
Feb 24 17:56:13 <jmbuser> glezos_fosdem: hi
Feb 24 17:56:36 <jmbuser> mether: I'm a-bloggin'
Feb 24 17:56:56 <mether> jmbuser: rock on
Feb 24 17:57:06 <couf> ow right I should send a mail aswell
Feb 24 17:57:28 <stickster> quaid: Well, for someone who goes to bed about 2am, you do pretty well IMHO
Feb 24 18:00:42 <couf> heh lol
Feb 24 18:01:15 <couf> okay folks, talk's over, we're getting ready here
Feb 24 18:01:27 <jmbuser> stickster: After extensive googling, I finally figured out your handle :-)
Feb 24 18:01:48 <stickster> jmbuser: rrr?
Feb 24 18:01:52 <glezos_fosdem> back
Feb 24 18:02:11 <glezos_fosdem> hi all from Brussels
Feb 24 18:02:14 <glezos_fosdem> its cool here
Feb 24 18:02:19 <glezos_fosdem> you should be jealous
Feb 24 18:02:26 <jmbuser> stickster: "handle" as in "stcikster"
Feb 24 18:02:29 <glezos_fosdem> at least, I'd be if I were you
Feb 24 18:02:32 <glezos_fosdem> :P
Feb 24 18:02:42 <jmbuser> s/stcikster/stickster/
Feb 24 18:02:55 <glezos_fosdem> quaid, sure. what's on your mind about PDF?
Feb 24 18:05:24 <jmbuser> stickster: U R referring to being a bass player, I believe
Feb 24 18:05:27 <couf> ping all
Feb 24 18:05:39 <jmbuser> couf: pong
Feb 24 18:05:42 <couf> we're ready here
Feb 24 18:07:01 <stickster> jmbuser: Close, although yes, I play that too
Feb 24 18:07:09 <stickster> jmbuser: q.v. http://www.stick.com/
Feb 24 18:08:15 <glezos_fosdem> stickster, any pointers on where to start with couf for the DUG to docbook process?
Feb 24 18:08:35 <stickster> glezos_fosdem: You'll want to work on a per-chapter/page basis
Feb 24 18:08:46 <glezos_fosdem> ok
Feb 24 18:08:47 * glezos_fosdem is now known as glezos
Feb 24 18:08:57 <glezos> ok
Feb 24 18:10:51 <glezos> stickster, so we just export from the page?
Feb 24 18:10:53 <glezos> \
Feb 24 18:11:13 <stickster> I just added a directory structure in CVS for them -- desktop-user-guide/FC-6/en_US/ is where you can put the XML files
Feb 24 18:11:27 <stickster> Yes, you can just export from the page. Be aware that they won't come out perfectly, but we can fix that XML stuff after it's in CVS
Feb 24 18:11:58 <stickster> For each page, name it something that makes sense, like the "chapter" title. Don't use "dug-" or anything at the beginning, it's unnecessary. For example, you could call one chapter "multimedia.xml"
Feb 24 18:12:44 <stickster> Set your CVSROOT appropriately as detailed in our CVS guidance, and then you can "cvs co desktop-user-guide"
Feb 24 18:12:53 <stickster> It'll just be some empty directories for now
Feb 24 18:12:58 <couf> right
Feb 24 18:14:10 <couf> so right now we're just exporting to docbook and naming the files
Feb 24 18:14:16 <stickster> Yup
Feb 24 18:14:21 <couf> do we need to export the toc aswell?
Feb 24 18:14:36 <stickster> couf: No, that part will be taken care of in rendering the DocBook to HTML or other formats
Feb 24 18:14:48 <stickster> Just export each of the chapter pages individually
Feb 24 18:15:27 <glezos> stickster, any automatic way to do that?
Feb 24 18:15:31 <couf> okay
Feb 24 18:15:31 <stickster> i.e. Introduction, Login, tour...
Feb 24 18:16:18 <glezos> BTW, I tried finding a guy from the KDE Docs team here to ask him about the PDF creation, but with no luck,
Feb 24 18:16:47 <glezos> stickster, which Makefile should we use as a base?
Feb 24 18:16:49 <stickster> glezos: You could adapt the beatconvert script in the release-notes module, but it would take some (admittedly light) Python wrangling
Feb 24 18:17:08 <glezos> stickster, maybe we should move that script to docs-common?
Feb 24 18:17:36 <stickster> glezos: You can use the one in documentation-guide
Feb 24 18:17:45 <stickster> glezos: Not yet. It's tightly tailored to the relnotes.
Feb 24 18:17:59 <glezos> ok
Feb 24 18:18:03 <stickster> one thing at a time :-)
Feb 24 18:18:06 <glezos> yup
Feb 24 18:18:10 <glezos> just asking
Feb 24 18:18:34 <stickster> Eventually I can see it being useful -- but eventually I could also see it being obsolete if ReST works better for our Drafts
Feb 24 18:18:39 * quaid continues the PDF intervweaving while he checks out the new module
Feb 24 18:19:04 <stickster> glezos: Oh, wait... You know, that script is actually even *less* useful than I was thinking
Feb 24 18:19:17 <stickster> It really was to work *around* the problem of not having docbook conversion on our "real" wiki!
Feb 24 18:19:27 <stickster> So it's actually quite obsolete right now :-D
Feb 24 18:19:33 <quaid> yeah, time to automate would be longer than by hand, with the current state of Wiki -> XML
Feb 24 18:19:36 <stickster> yup
Feb 24 18:20:26 <glezos> stickster, ReST? whats up with that?
Feb 24 18:21:10 <quaid> stickster: side note on that, are you thinking we should convert Docs/Beats/ to use ReST? and if so, are we going to make it harder to edit?
Feb 24 18:22:34 <quaid> glezos: so, there are two parts to PDF production for us -- is it in our toolchain (can you do make pdf), and does it work (is the output nice, does it throw errors for now reason)
Feb 24 18:22:55 <quaid> the answer to that is, yes, we can do it with our tools, and, yes, it is often broken
Feb 24 18:23:09 <glezos> quaid, lets concentrate on the second
Feb 24 18:23:56 <stickster> quaid: I don't think it will be much harder to edit. There's a few more markup possibilities, but it's a *lot* more human-readable than XML
Feb 24 18:24:01 <couf> okay I've got all the XML's
Feb 24 18:24:18 <stickster> couf: OK, you have them all in d-u-g/FC-6/en_US right?
Feb 24 18:24:28 <couf> stickster: yep
Feb 24 18:24:52 <glezos> I'm adding the Makefile
Feb 24 18:24:54 <stickster> Then you can do "cvs add *.xml" and then "cvs ci -m 'Initial commit from wiki' *.xml"
Feb 24 18:25:03 <stickster> (inside that dir of course)
Feb 24 18:25:23 * stickster is going to need to run in a minute or two, for a little wihle
Feb 24 18:25:25 <quaid> glezos: ok, so the standard passivetex in Fedora is problematic; it has always had problems, as soon as one is fixed, another arises; Veillard says we should be able to file bugs and etc, but ... it's going to take some folks some concentrated effort to figure out if the passivetex could work for anything.
Feb 24 18:25:55 <couf> btw, ugly xml layout
Feb 24 18:25:57 <glezos> ok lets forget about that then for now
Feb 24 18:26:01 <quaid> glezos: the guy who does the RHEL docs toolchain tried to get passivetex to work for him for ... six months? and they kept running into the "ugly table output" and a few other things we've all seen.
Feb 24 18:26:05 * couf has comitted
Feb 24 18:26:14 <stickster> Yeah, it was pretty horrific
Feb 24 18:26:24 <quaid> glezos: so, for FOP we're waiting on the Java team; we can't make anything without them.
Feb 24 18:26:36 <quaid> so that leaves us with hacking in additional pathways into our Makefile
Feb 24 18:26:55 <glezos> quaid, dblatex?
Feb 24 18:27:10 <quaid> glezos: I haven't looked, is it packaged for Fedora?
Feb 24 18:27:12 <jmbuser> glezos: the KDE way
Feb 24 18:27:24 <couf> quaid: nope
Feb 24 18:27:45 <quaid> I think it would be great to add other methods, but I'm concerned about us chasing something that doesn't work; do the KDE folks report any problems with the usage?
Feb 24 18:27:55 <stickster> glezos: I thought there was a translation problem with the KDE way of doing things
Feb 24 18:28:00 <stickster> Am I remembering wrong?
Feb 24 18:28:09 <jmbuser> quaid: there's a modified dblatex in tar.gz package
Feb 24 18:28:17 * stickster thinks back to that URL he threw ino #f-docs like a grenade the other day
Feb 24 18:28:25 <quaid> also to note, the FOP way is aligned with the upstream DocBook people; Java is what they use for this; so we hoped to catch the "wind fills all sails" method
Feb 24 18:28:34 <quaid> stickster: yeah, jmbuser captured it into his pages
Feb 24 18:29:28 <stickster> glezos: That Makefile can go into d-u-g/FC-6/ by the way
Feb 24 18:30:01 <stickster> Oops, HunkyCaps alert
Feb 24 18:30:03 <stickster> Oh well, no biggie
Feb 24 18:30:21 <stickster> could actually work to advantage with some automated tools
Feb 24 18:30:26 <couf> stickster: what's next?
Feb 24 18:31:09 <quaid> xmlformat is next
Feb 24 18:31:18 <stickster> heh
Feb 24 18:31:21 <quaid> shall I?
Feb 24 18:31:25 <stickster> please do, sir
Feb 24 18:31:27 <quaid> or shall i teach how? :)
Feb 24 18:31:28 <stickster> both
Feb 24 18:31:34 <couf> yeah both ;-)
Feb 24 18:31:38 <quaid> ok, so the XML needs to get some indenting
Feb 24 18:31:47 <quaid> the best way is with xmlformat, which is in docs-common
Feb 24 18:31:50 <couf> heh, figured that
Feb 24 18:31:57 <quaid> so I'm going to do a quick loop and commit back, one second and I'll show you how
Feb 24 18:32:04 <glezos> ok, added a first Makefile and rpm-info.xml
Feb 24 18:32:08 <glezos> fixing the errors now
Feb 24 18:32:11 <stickster> glezos: Cool
Feb 24 18:33:36 <stickster> quaid: I'll probably throw my usual Emacs local-variables in the bottom at some point, too
Feb 24 18:33:38 * quaid still tweaking, one minute more
Feb 24 18:33:40 <stickster> np
Feb 24 18:33:45 <couf> :)
Feb 24 18:35:37 <quaid> for i in ls *xml; do xmlformat -f ../../../docs-common/bin/xmlformat-fdp.conf $i > tmpfile; mv tmpfile $i; done
Feb 24 18:35:40 <quaid> so I did that
Feb 24 18:35:43 <stickster> The xmlformat thing quaid is doing is basically just "prettying up" the text with good indentation, etc. so it's easier to read
Feb 24 18:35:52 <quaid> now when you cvs up -d, you'll get lots of pretty XML
Feb 24 18:36:33 <quaid> the -f docs-common/bin/xmlformat-fdp.conf is the customized configuration file we have done for FDP
Feb 24 18:37:00 <quaid> it tells the formatter to e.g. ignore <screen> blocks, which are blocks of code you don't want to have the whitespacing formatted out
Feb 24 18:37:02 <stickster> OK, added the local variables at end too
Feb 24 18:37:05 <stickster> so now you can "cvs up" again
Feb 24 18:37:11 <glezos> thanks guyws
Feb 24 18:37:14 <quaid> those are usefule for Emacs users
Feb 24 18:37:28 <quaid> and keeping things consistent
Feb 24 18:37:51 <quaid> now you guys can safely open Emacs and start hacking on the XML without it being crazy
Feb 24 18:38:04 <stickster> Because as everyone knows, Emacs is the best way to do all this ;-) *snicker
Feb 24 18:38:31 <quaid> heh
Feb 24 18:38:33 <glezos> :)
Feb 24 18:38:47 <quaid> is anyone working on the parent XML file? e.g. en_US/deskto-user-guide.xml?
Feb 24 18:38:54 <stickster> Ooo, there you go
Feb 24 18:38:56 <quaid> if not, I can hack one together quickly
Feb 24 18:39:01 <stickster> Nah, let the newbies do it
Feb 24 18:39:19 <quaid> use the release-notes/devel/en_US/release-notes.xml as a starting place
Feb 24 18:39:23 <couf> right
Feb 24 18:39:52 <quaid> sorry, s/release-notes/RELEASE-NOTES/
Feb 24 18:40:43 <quaid> in that file, I recommend chopping out or just ignoring the <!ENTITY BUG-URL and TINY-BUG-URL for now
Feb 24 18:40:53 <stickster> yup
Feb 24 18:41:57 <quaid> yeah, you are right, this is a relatively easy file to modify, and it is good stuff to look at
Feb 24 18:42:49 <glezos> the list of XML files are duplicated in the Makefile and the desktop-user-guide.xml, right?
Feb 24 18:44:27 <quaid> right
Feb 24 18:44:51 <couf> so the different xml-files should get a heading right?
Feb 24 18:44:58 <quaid> the d-u-g.xml is actually pulling the files in with XIncludes, where the Makefile needs the list of files ... well, I forget why the makefile needs the list :)
Feb 24 18:45:04 <glezos> and since r.h.c is down, which package provides xmlto?
Feb 24 18:45:33 <quaid> couf: yes, each file is a full xml file, with a header that says e.g.'chapter' instead of ;book'
Feb 24 18:46:16 <quaid> rpm -q --whatprovides which xmlto
Feb 24 18:46:18 <quaid> xmlto-0.0.18-13.1
Feb 24 18:47:30 <glezos> thanks
Feb 24 18:48:02 <quaid> couf: you can look at the files in release-notes/devel/en_US/ to see how each XML should be prepared.
Feb 24 18:51:21 <couf> quaid: yeah
Feb 24 18:52:23 <couf> quaid: getting error with tables-stuff, should this be changed in xml?
Feb 24 18:52:44 <couf> we're working on Communications.xml to know how everything works
Feb 24 18:53:27 <couf> exact error is:
Feb 24 18:53:33 <couf> ./Communications.xml:404: element table: validity error : Element table content does not follow the DTD, expecting ((blockinfo? , (title , titleabbrev?) , indexterm* , textobject* , (graphic+ | mediaobject+ | tgroup+)) | (caption , (col* | colgroup*) , thead? , tfoot? , (tbody+ | tr+))), got (caption tgroup para para )
Feb 24 18:55:13 * quaid looks
Feb 24 18:56:28 <quaid> ok, 404 should be the line number
Feb 24 18:57:31 <couf> yeah, we're getting some of those error's
Feb 24 18:57:31 <quaid> can you check in this version of Communications.xml so I can see it?
Feb 24 18:57:43 <glezos> quaid, its checked in
Feb 24 18:59:01 <quaid> with the DOCTYPE header included?
Feb 24 18:59:53 <couf> quaid: not yet, hang on
Feb 24 18:59:56 <couf> different version
Feb 24 19:00:01 <quaid> k
Feb 24 19:01:16 <couf> now it should be
Feb 24 19:02:56 <quaid> ok, good, now I'm looking at the same line numbering
Feb 24 19:03:02 <glezos> quaid, this cool guy sitting next to me hacking on the DUG is *also* documenting each step for future reference.. how cool is that.
Feb 24 19:03:32 <jmbuser> thanks, cool guy!
Feb 24 19:03:33 <quaid> http://www.docbook.org/tdg/en/html/table.html is where I'm looking
Feb 24 19:03:41 <quaid> glezos: :D
Feb 24 19:04:25 <quaid> ah, the admonition problem!
Feb 24 19:04:38 <quaid> ok, so here's one of the problems we currently have with wiki => XML
Feb 24 19:04:45 * stickster gets back from furniture moving
Feb 24 19:04:58 <quaid> there is no sense of an admonition in the Wiki
Feb 24 19:05:08 <quaid> we use a e.g. .png){kind=small}
in a table, but that is a visual formatting
Feb 24 19:05:23 <quaid> so, the table that is erroring here needs to be replaced with a proper admonition
Feb 24 19:05:34 <quaid> in fact, you'll probably find that _all_ tables in the XML are in fact admonitions
Feb 24 19:05:36 * stickster hacks a couple things in d-u-g.xml
Feb 24 19:05:59 <quaid> does that make sense or should I update this XML to how what I mean?
Feb 24 19:07:06 <couf> quaid: it makes some sense, but do show us
Feb 24 19:08:23 <quaid> ok, fix checked in
Feb 24 19:08:27 * glezos feels that these non-automatic procedures take the Handbook off the table completely... :(
Feb 24 19:08:35 <quaid> that is, not sure it will make the doc build stop breaking, but it should help :)
Feb 24 19:08:57 <quaid> glezos: this is the broken part that we had all the GSoC coding done for ... which we are still not using
Feb 24 19:09:17 * jmbuser makes note to self to do DocBook admonitions in comments to speed things up in the future
Feb 24 19:09:18 * stickster fixes prolog in d-u-g.xml
Feb 24 19:09:19 <quaid> the "new" path is much better, for example, that's why we use the funky admonition style in the Docs/Beats/
Feb 24 19:09:39 * stickster notes that ReST has ability to do "real" admonitions
Feb 24 19:09:58 <stickster> Including all five of our types for DocBook, meaning they should come out correctly both visually and XMLish
Feb 24 19:10:33 <jmbuser> stickster: another time you'll have to explain ReST - it kinda came out of nowhere for me
Feb 24 19:10:59 <stickster> jmbuser: http://docutils.sourceforge.net/rst.html
Feb 24 19:11:17 <jmbuser> stickster: thanks
Feb 24 19:12:07 <couf> quaid: right got that, what are the possible admonittions?
Feb 24 19:12:35 <quaid> ok
Feb 24 19:12:44 * couf notes: one file to help out, the rest will be doable, I hope
Feb 24 19:13:03 * stickster adds doc-entities.xml file too
Feb 24 19:13:19 <stickster> couf: note, tip, important, caution, warning
Feb 24 19:13:33 <couf> stickster: thanks
Feb 24 19:13:37 <stickster> see also the Documentation Guide for how to use each one
Feb 24 19:13:38 <quaid> http://fedoraproject.org/wiki/WikiEditing#Admonitions
Feb 24 19:13:47 * quaid saves that
Feb 24 19:14:31 <quaid> that helps, because the wiki only shows you which 
was used
Feb 24 19:16:36 * stickster corrects relative path in doc-entities.xml
Feb 24 19:16:41 <stickster> Everybody make sure you cvs-up
Feb 24 19:17:51 <couf> stickster: hmm getting errors now
Feb 24 19:17:58 <stickster> couf: To be expected.
Feb 24 19:18:11 <couf> stickster: aah okay
Feb 24 19:18:12 <stickster> couf: You mean 'C'onflicts in CVS?
Feb 24 19:18:21 <stickster> Or when you do a "make validate-xml"?
Feb 24 19:18:22 <couf> stickster: no, in the make
Feb 24 19:18:27 <stickster> OK, yes, perfectly expected at this point.
Feb 24 19:18:34 <quaid> right
Feb 24 19:18:39 <stickster> There's a lot of XML still to be fixed.
Feb 24 19:18:41 <couf> right
Feb 24 19:18:52 <stickster> couf: Believe it or not, those error message *will* tell you exactly where the problem is.
Feb 24 19:18:54 <quaid> the technique is, you go through and fix all you know (such as table => admonition)
Feb 24 19:18:59 <quaid> then you build, it breaks, and you fix that
Feb 24 19:19:08 <quaid> repeat until it stops breaking
Feb 24 19:19:16 <stickster> You just need to take your time and read the error messages... believe me, it takes a *lot* of patience sometimes!!!
Feb 24 19:19:25 <quaid> one clue is ...
Feb 24 19:19:39 <quaid> it dumps all the output for you, so the error is often buried somewhere
Feb 24 19:20:05 <quaid> if you start at the bottom of the error content and work backward, you can find the spot where "warning" becomes "error"
Feb 24 19:20:15 <stickster> Ah, I also needed to commit the new Makefile stuff, sorrry
Feb 24 19:20:18 <stickster> cvs up again
Feb 24 19:20:18 <couf> aah
Feb 24 19:20:27 <stickster> Now you'll get different and all-new errors!
Feb 24 19:20:34 <couf> stickster: that's better :)
Feb 24 19:20:45 <couf> it was an error on your doc-entities, that's way I mentioned it
Feb 24 19:20:53 <couf> now gone
Feb 24 19:21:12 <stickster> Yup, my fault entirely, forgot to tell the Makefile they were there so it could build the .ent from the .xml
Feb 24 19:21:55 <couf> heh, no problem
Feb 24 19:22:24 <stickster> quaid: Are we doing this as <article> with <section>s or <book> with <chapter>s (like other guides)?
Feb 24 19:23:02 * stickster asks before we start putting prologs in all the files
Feb 24 19:23:14 <quaid> book and chapter, i thought
Feb 24 19:23:22 <stickster> cool
Feb 24 19:24:10 * stickster makes change in Communications, should be easily mergeable
Feb 24 19:24:39 <stickster> OK, committed
Feb 24 19:27:38 <couf> so I just committed the new Communications with all admonitions
Feb 24 19:27:50 <couf> stickster, quaid: could anyone just check it?
Feb 24 19:28:20 * stickster needs to correct XPointer real quick
Feb 24 19:31:40 * stickster is fixing some rpm-info problems, hang on
Feb 24 19:31:55 <stickster> rpm-info must be valid for anything else to work properly :-)
Feb 24 19:32:39 <jmbuser> (makes small talk) how did the talks go?
Feb 24 19:33:37 <stickster> OK, couf, good work, that file is valid
Feb 24 19:33:44 <stickster> cvs up to get my changes
Feb 24 19:34:18 <stickster> couf: Well, it still needs to get all the attachments added in the XML now
Feb 24 19:34:51 <glezos> stickster, you do all each time you produce the doc from the Beats?
Feb 24 19:35:03 <couf> stickster: so how do you do that
Feb 24 19:35:03 <couf> ?
Feb 24 19:35:20 <stickster> couf: Just download the attachments and "cvs add" and "cvs commit" them in en_US/figs/
Feb 24 19:35:40 <stickster> glezos: Well, it's much easier when the docs are written to specific XML porting standards... :-)
Feb 24 19:35:48 <stickster> And hopefully if we use ReST that will be even easier
Feb 24 19:36:10 <stickster> And the rpm-info and Makefile stuff gets out of the way only once per doc
Feb 24 19:36:18 <stickster> But yes, we have to do a little XML hand-cobbling anytime we do a mass import
Feb 24 19:37:04 <couf> stickster: should I keep the names?
Feb 24 19:37:45 <stickster> couf: Sure, I don't think that's a problem.
Feb 24 19:37:52 <stickster> Bits are cheap if we end up needing to change them.
Feb 24 19:38:09 <stickster> Some things that are going to need fixing throughout:
Feb 24 19:38:18 <stickster> Turn all the menu selections into <menuchoice> elements
Feb 24 19:38:33 <stickster> Make sure <ulink> elements are concise
Feb 24 19:38:49 <stickster> couf: By the way, you should make sure all the attachments are no bigger than 500px wide
Feb 24 19:39:04 <stickster> You can use ImageMagick's "mogrify" command for this
Feb 24 19:40:19 <couf> stickster: wide and/or high?
Feb 24 19:40:40 <stickster> wide
Feb 24 19:40:50 <quaid> it would be cool if it had a 'valmorify' command
Feb 24 19:40:55 <stickster> ?
Feb 24 19:41:13 <quaid> sorry, Team America reference
Feb 24 19:41:21 <stickster> heh
Feb 24 19:41:44 <quaid> they use 'valmorification' the way Calvin and Hobbes use 'transmogrify'
Feb 24 19:42:11 * stickster needs to read writers list more carefully
Feb 24 19:42:43 <couf> stickster: educate me
Feb 24 19:46:53 <couf> stickster: mogrify -geometry 500 file.png?
Feb 24 19:47:04 <stickster> couf: Yes, I believe that's right
Feb 24 19:47:39 <stickster> Or it might be 'mogrify -scale 500 file.png'
Feb 24 19:48:12 <couf> it seems to work
Feb 24 19:48:30 <stickster> OK
Feb 24 19:48:43 * stickster updates colophon in rpm-info, time to cvs up again :-)
Feb 24 19:50:37 <stickster> whoops, one more change needed there
Feb 24 19:51:59 <stickster> One more cvs up :-)
Feb 24 19:53:46 <stickster> couf: OK, now for each of those locations in the document, you'll need to have an appropriate XML element. You can find examples all over, like the Installation Guide for instance
Feb 24 19:54:17 * stickster wonders how ReST parsers might deal with this -- probably better.
Feb 24 19:54:55 <couf> stickster: I see .eps files everywhere, do these need to be created aswell?
Feb 24 19:55:17 <stickster> Those are for the print version in PDFs; you probably don't need to do anything with those for now.
Feb 24 19:56:04 <stickster> My personal opinion is anything like that should be built from the source PNGs at render time anyway.
Feb 24 19:56:20 <couf> right
Feb 24 19:56:21 <stickster> Minimize what we have to store in the SCM, in other words
Feb 24 19:57:55 <quaid> +1
Feb 24 20:00:59 <couf> stickster: I think somethings wrong with the placement of the figs
Feb 24 20:01:12 <couf> shouldn't it be FC-6/figs
Feb 24 20:01:22 <couf> in stead of FC-6/en_US/figs?
Feb 24 20:01:39 <quaid> hmm, they can be translated, right?
Feb 24 20:01:44 <quaid> theoretically, that is
Feb 24 20:01:53 <quaid> so each $LANG needs its own set? or ...?
Feb 24 20:02:26 <stickster> quaid: I believe the build tools take care of this. If they're translatable (i.e. screenshots) they should be in the $LANG directory. If no others are found, the $PRI_LANG ones get used in any $LANG in $OTHERS
Feb 24 20:02:31 <couf> in install guide it's just beneath the devel or fc-x version
Feb 24 20:02:41 <stickster> Yeah, the build tools will search in several places for these.
Feb 24 20:03:01 <stickster> The situation in the Installation Guide is simply because no one ever provides translated screen shots, and I was too lazy to move them for now.
Feb 24 20:03:04 <stickster> :-D
Feb 24 20:03:36 <couf> the makefile seems to be missing the right directory
Feb 24 20:03:41 <stickster> rrr?
Feb 24 20:04:11 <couf> it's doing: [ ! -d figs ] || copy-figs -v -f '*.png' -l en_US figs desktop-user-guide-en_US
Feb 24 20:04:18 <couf> and it isn't copying anything
Feb 24 20:04:38 <stickster> Arrrgh
Feb 24 20:05:14 * stickster fixes prologs in all XML fiels
Feb 24 20:05:14 <stickster> *files
Feb 24 20:05:26 <couf> heh
Feb 24 20:05:54 <stickster> couf: Please commit your changes to the XML file so I can test here
Feb 24 20:07:07 <couf> stickster: done
Feb 24 20:10:09 <stickster> Heh, leave it to Tommy to write shell scripts in the most arcane possible way.l
Feb 24 20:10:20 <stickster> Why use $VARNAME when you can use $c ?
Feb 24 20:11:17 <stickster> OK... let's see if we can fix this
Feb 24 20:13:06 <couf> so okay, just to clearify, if I copy the figs directory one up, it works
Feb 24 20:13:33 <quaid> yes
Feb 24 20:14:00 <couf> so should I move the dir on cvs or not?
Feb 24 20:14:04 <stickster> couf: Right
Feb 24 20:14:14 <stickster> I'm taking care of it, making it a little more obvious they're to be translated
Feb 24 20:14:20 <couf> stickster: okay
Feb 24 20:14:52 <stickster> Why does my po dir keep disappearing? OH well
Feb 24 20:18:11 <stickster> OK, they're in the right place now
Feb 24 20:18:18 <stickster> cvs up and so forth :-)
Feb 24 20:20:43 <stickster> Oh crap, that is going to suck now.
Feb 24 20:21:00 <couf> okay works
Feb 24 20:21:03 <stickster> OK, our whole copy-figs thing is completely fux0r3d.
Feb 24 20:21:22 <stickster> couf: Well, it copies, but the sucky part is that now the lang codes are going to interfere with the L10N work
Feb 24 20:21:50 <couf> yeah, will be a problem for a bit later
Feb 24 20:21:57 <stickster> Because I gave them names with a L10n code, it means the XML has to point to that file name. When a translator translates, they may not get the chance to change that file name.
Feb 24 20:21:58 <couf> let's first get the full xml
Feb 24 20:22:01 <stickster> Thus the suck.
Feb 24 20:22:08 <stickster> Sure
Feb 24 20:22:09 <couf> right
Feb 24 20:22:23 <stickster> couf: All right, what else do you need to keep going?
Feb 24 20:22:34 <stickster> I need to get some lunch and a bunch of other things done here today
Feb 24 20:22:47 <couf> not much I think, I'll do a recap of what I know now
Feb 24 20:23:02 <couf> 1) check header of each xml-doc + add to parent file
Feb 24 20:23:11 <couf> 2) change admonition stuff
Feb 24 20:23:14 <couf> 3) figures
Feb 24 20:23:19 <couf> right?
Feb 24 20:23:37 <stickster> that will be a great start, also 1a) make sure the top-level element of each file is a <chapter> and not a <section> or <article>
Feb 24 20:23:44 <stickster> (close the tag at the end too)
Feb 24 20:23:54 <couf> right
Feb 24 20:24:07 <stickster> cool then, don't worry about validation problems -- do your best and I will be happy to help house-clean later
Feb 24 20:24:14 <couf> okay
Feb 24 20:24:31 <stickster> We'll also need to figure out this stupid figs deal.
Feb 24 20:24:45 <stickster> It could be my lack of clue about the copy-figs script, I'll re-read when I'm not starving :-D
Feb 24 20:26:17 <couf> all righty, gonna try to get the most done as long as time permits it here
Feb 24 20:26:23 <couf> the rest'll be for tomorrow
Feb 24 20:28:27 <jmbuser> couf: I tried to pay careful attention to what you guys were doing, but i got interrupted several times by phone calls - and my brain is tired from a full day's work.
Feb 24 20:29:07 <couf> jmbuser: I'm trying to keep a list of what we've done, I'll pass it on to you, once it's got some cleanup doneµ
Feb 24 20:29:10 <jmbuser> couf: Therefore, any notes you have - and I am saving this chat transcript as well - will be helpful.
Feb 24 20:29:58 * jmbuser changes subject
Feb 24 20:30:10 <jmbuser> couf: so, how's FOSDEM?
Feb 24 20:30:31 <couf> it's good, a lot of people around
Feb 24 20:30:39 <couf> fedora seems to be very active here in Europe
Feb 24 20:30:47 <glezos> back from Django
Feb 24 20:30:49 <couf> got to meet some nice people, like the guy next to me
Feb 24 20:31:00 <couf> s/guy/guys
Feb 24 20:31:29 <glezos> ok, I was convinced today that it would be impossible to produce a Handbook from the wiki.
Feb 24 20:35:11 <jmbuser> glezos: "rest" sounds interesting, once I figure it out
Feb 24 20:35:28 * ajaaya (n=ajaaya@wsip-68-15-202-211.ok.ok.cox.net) has joined #fedora-docs
Feb 24 20:36:36 <jmbuser> couf: Thanks in advance
Feb 24 20:36:54 <glezos> jmbuser, docutils?
Feb 24 20:37:37 <jmbuser> glezos: yes, although I could use a rest :-)
Feb 24 20:38:12 <glezos> :)
Feb 24 20:38:37 <couf> jmbuser: np
Feb 24 20:39:47 <ajaaya> #fedora-docs: hello
Feb 24 20:40:07 <jmbuser> ajaaya: hi
Feb 24 20:40:32 <ajaaya> jmbuser: did I miss the DUG to XML conversation?
Feb 24 20:41:22 <jmbuser> ajaaya: yes, but I am logging the session and our guys at FOSDEM are producing notes
Feb 24 20:41:42 <ajaaya> jmbuser: thanks mate
Feb 24 20:43:46 <jmbuser> ajaaya: I will put the log under my (not so) private wiki sandbox as JohnBabich/FosdemDocs in a few hours
Feb 24 20:44:33 <couf> lol
Feb 24 20:44:39 <ajaaya> jmbuser: kewl