Re: freeing FOP
by Karsten Wade
On Wed, 2006-02-22 at 00:45 -0500, Thomas Fitzsimmons wrote:
> Hi,
>
> I finished building FOP and its dependencies on the free Java stack. To
> pare the dependency tree I built Batik without Rhino support. If such a
> feature-limited Batik is acceptable in Fedora Extras then we'll only
> need to add about five new packages, rather than the ~80 packages we'd
> need for a Rhino-enabled Batik.
Rhino is the Mozilla JavaScript interpreter, right? We don't have any
need for that I know of. When someone else with such a need packages
Rhino for Extras, I suppose we can add support back in.
Tommy informed me that our main usage of Batik is for batik-rasterizer
for SVG files. If batik-rasterizer works without Rhino, we're fine.
> Batik 1.6 also has dependencies on com.sun classes in its JPEG- and
> TIFF-encoding code. These dependencies have been removed in Batik CVS
> but for now I've disabled JPEG- and TIFF- output in my test RPM.
>
> Unfortunately, FOP has two non-free dependencies, neither of which has a
> free drop-in replacement. These are Jimi and JAI, both image-handling
> frameworks. From the FOP error output it seems that JAI is the
> preferred framework with Jimi providing a fallback. It may be possible
> to provide a second fallback that uses the standard ImageIO framework
> which is implemented in the free stack, but that will require upstream
> changes. For now free FOP cannot handle images.
Our images need is only for PNG support. That lets us output to screen
and printed formats.
Does it just strip out/ignore image calls in the FO?
> To test my FOP RPM I ran build-hig-pdf.sh from the GNOME Human Interface
> Guidelines CVS repository. I've attached a log of the console output
> and the generated PDF. A GCJ bug is preventing the compilation of FOP's
> hyphenation patterns which explains why FOP can't find them. I'll file
> a bug for this shortly.
>
> Perhaps the documentation team can review the attached PDF? Shall I go
> ahead and propose FOP and its dependencies for Fedora Extras inclusion,
> even though it currently lacks image support? I'm wondering if that
> would be a good way for the docs team to track my progress and offer
> feedback. Obviously until the image support issues are resolved the
> packages will have to be considered preview-quality.
The attached PDF looks stellar, from a visual/format stand point. I
didn't see any visual bugs in my comb through, and it was nice to see
things such as URLs finally formatted well, such as, this is the link
text [URI].
We can't really use it in production without image support, but I'm sure
some of us would like to see how it handles our most difficult XML to
PDF conversions.
Thanks so much for working on this. Let us know how the packaging
progresses, and I'll roust up a few folks who have been complaining
about PDF output and give this to test with. :)
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Content Services Fedora Documentation Project
http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
18 years, 2 months
Re: install-guide/po zh_CN.po,1.1,1.2
by Stuart Ellis
On Wed, 2006-02-22 at 15:21 +0800, Yuan Yijun wrote:
> Investigation Report
> ======
> * install po2xml requires kdesdk which brings in a whole new KDE on my
> little HDD.
Yes, I found that too :(.
> * touch en/* would force make po execution
OK.
> * po2xml always cries for missing strings if there is nested xml tags
> I guess, but I'm not sure. xml2po in gnome-doc-utils works well. I
> think we can remove po2xml from Makefile.common and fdp-functions
Hopefully Paul or Tommy can chime in here - I don't really know enough
about xml2po vs. po2xml to have an opinion.
> * revdescription tag in zh_CN/fdp-info.xml is blank due to no
> translations available. Modify xsl to use en descriptions.
> * now relnotes/zh_CN can build
>
>
> --
> bbbush ^_^
--
Stuart Ellis
stuart(a)elsn.org
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
GPG key ID: 7098ABEA
GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA
18 years, 2 months
Re: docs-common Makefile.common,1.66,1.67
by Tommy Reynolds
Uttered "Tommy Reynolds" (jtr) <fedora-docs-commits(a)redhat.com>, spake thus:
> Modified Files:
> Makefile.common
> Log Message:
> Revert prior changes. Document template purpose.
> -PO2XML =xml2po
> +PO2XML =po2xml
> #########################################################################
> +# Define a template to generate the locale-specific XML files given the
> +# original ${PRI_LANG} file and an updated po/${LANG}.po file.
> define XML_template
> $(patsubst ${PRI_LANG}/%,${1}/%,${2}):: ${2} po/${1}.po ${1}
> - ${PO2XML} -p po/${1}.po ${2} >$$@
> + ${PO2XML} ${2} po/${1}.po >$$@
> endef
My sincere apologies for not describing my (mis)understanding of the
translation process earlier. Below shows how I envisioned this process
working. The file maintenance steps, at least, seem to be very automated;
the translator need concentrate on editing either the .PO or .POT file and
a single make(1) target: make html-${LANG} or make xml-${LANG}, at their
preference.
The steps involved in the .POT / .PO / .XML file maintenance are:
1) Produce original XML in a ${PRI_LANG} subdirectory.
2) The target "make pot" can be used to generate a single .POT file from
all of the ${PRI_LANG} XML files. The "make pot" gets run automatically
when a ${PRI_LANG} file is changed and one of the following steps are used.
The resulting file is the po/${DOCBASE}.pot file.
3) The target "make po" generates an updated po/${LANG}.po file whenever the
.POT changes. Translation entries from the .POT file are merged into the
.PO file. The "make pot" rule is run first if necessary.
4) The target "make xml-${LANG}" generates all the translated XML files into
the "${LANG}/" directory. This is done by applying the .PO files against
the ${PRI_LANG} XML files using po2xml(1). The "make po" rule is run first
if necessary.
5) The target "make html-${LANG}" renders the XML in ${LANG}/*.xml to produce
translated HTML in a "${DOCBASE}-${LANG}/" folder. The "make xml-${LANG}"
rule is run first if necessary.
So, as I (mis)understand the process, the very first action a translator
should take is to:
a) Add the appropriate locale to the ${OTHERS} list; and
b) "make po"
c) Insert translated entries into either the .PO or .POT file; the .PO file
serves as the translation archive and is preserved across builds but the
.POT file is rewritten every time the matching XML file changes.
d) "make xml-${LANG}" to view the applied XML translations. The target
"make html-${LANG}" should work equally well.
For later translation sessions, the translator repeats the steps:
I) "make po"
II) Insert translations into either the .PO or .POT file
III) "make xml-${LANG}" or "make html-${LANG}" as desired.
If this technique does not match the translator's expectations, we need to
adapt the process.
Cheers
18 years, 2 months
Re: install-guide/po zh_CN.po,1.1,1.2
by Yuan Yijun
在 06-2-18，bbbush Yuan Yijun<fedora-docs-commits(a)redhat.com> 写道：
> Author: bbbush
>
> Update of /cvs/docs/install-guide/po
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv19498
>
> Modified Files:
> zh_CN.po
> Log Message:
> the old way of working
>
>
I'm not using "make po-zh_CN" to get the po files. Instead I have to
use Andrew's scripts, that is to replace &ENTITIES with &ENTITIES
before running xml2po. Could this be fixed or I missed something?
--
bbbush ^_^
18 years, 2 months
Re: release-notes/zh_CN ArchSpecific-zh_CN.xml, 1.1, et. al.
by Tommy Reynolds
Uttered "Yuan Yijun" (bbbush) <fedora-docs-commits(a)redhat.com>, spake
thus:
> Removed Files:
<snip>
> Log Message:
> hope I don't have to re-add them again
Me, too.
Have you had any progress about the language-specific entities you had
mentioned earlier? If nothing has been done, I have some ideas I can
try, but I don't want to duplicate any effort.
Cheers
18 years, 2 months
goals for a year's tenure
by Karsten Wade
It's time to set the goals for my year's tenure as Fedora
Documentation Project Management Committee (PMC) chair.
What do you think is important for this project?
What should my goals and the project's goals be for the year?
From the beginning, I've agreed with Greg DeKoenigsberg that our role as
Red Hat kickstarters of Fedora was to:
i) Make things rock and roll;
ii) GTF out of the way and let it roll!
I've been witnessing this with Fedora Extras, and it is impressive.
Nine months ago I set myself a personal goal of eighteen months to do
just that in the Docs Project -- make things rock, then get out of the
way.
Things being what they be, I'm upping to 21 months total, so February of
2007. ;-D
Community leaders abound, but the FC 6 development cycle requires me to
keep the momentum going as someone who can shake-and-stir inside of Red
Hat. That was the core of my original plan, to get the project out from
Red Hat's wing. Seeing through FC 6 development and mid-way into FC 7
should be just about the right timing for me to retire, I reckon.
Therefore, I'm working on my goals and aspirations for the next year:
http://fedoraproject.org/wiki/KarstenWade/FDPChair/Goals2006
The goals have some metrics assigned to them. That's how we know they
are done, when the metrics are met or exceeded. But they are a starting
point, what I think might be important. So, back to the top ...
What do you think the project's goals should be for the next year?
How about my goals as the chair/leader?
I'm figuring it is our responsibility to set our goals and tell the
Fedora Foundation board about them. They may have some additional goals
for us, and we may in turn have some to ask of them. Ideally, our goals
should be a subset of their goals, which isn't that hard to do. :)
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Content Services Fedora Documentation Project
http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
18 years, 2 months
New GPG Key
by Cody R. DeHaan
As a result of some technical problems, I have lost my original GPG
key. As a result, I have created a new key, which I have uploaded to
the pgp.mit.edu server.
Key ID: A87EAE24
Fingerprint: 21DE 1297 62BA 69B6 4534 B997 F221 2E79 A87E AE24
If you will notice, my old key is listed with an e-mail address of
"Cody.DeHaan(a)gmail.com". My new key is all lowercase:
"cody.dehaan(a)gmail.com" Obviously, the new key also has a newer
creation date.
I apologize for the inconvenience.
Regards,
Cody DeHaan
--
Cody DeHaan
Fedora Documentation Project
GPG: 21DE 1297 62BA 69B6 4534 B997 F221 2E79 A87E AE24
18 years, 2 months
[ANN] Fedora Project Wiki Policy Change
by Patrick W. Barnes
The Fedora Foundation has decided that all Fedora documentation, including the
fedoraproject.org wiki, will be licensed under the terms of the Open
Publication License 1.0[1] without options.
Unfortunately, the Fedora Project does not have copyright privileges over the
wiki's existing content. Since we have allowed anyone to edit the wiki
without any sort of licensing or copyright assignment, we cannot cover the
existing content without the agreement of each contributor. To solve this
issue, we have come up with a plan[2]. Our plan will require that all
contributors complete the CLA in the Fedora Account System[3] before joining
the EditGroup.
In order to facilitate our new changes, the EditGroup will be frozen effective
immediately and through the weekend. Those of you who are in the EditGroup
can continue to make edits during that time, but no new contributors are to
be added to the EditGroup during the freeze.
Everyone who is in the EditGroup but has not completed the CLA will be removed
after this weekend. If you are currently in the EditGroup and have not
completed the CLA, please take the time to do so now. This agreement will
allow us to license your contributions under the OPL. If you have completed
the CLA, but are removed after the weekend, contact someone in the revised
EditGroup to add you again.
All current EditGroup members who are removed will have their name added to a
tracking page[4]. If your name is moved to that list, you will need to
complete the CLA and remove yourself from the list to indicate that you agree
to having your past contributions licensed under the OPL. DO NOT REMOVE
OTHERS from this list. It will be monitored. After an undetermined waiting
period, all contributions made by names still on this list will be removed
from the wiki.
If you would like to learn more about our licensing and other legal terms,
visit the Legal page[5] on the wiki.
[1]
http://fedoraproject.org/wiki/Legal/Licenses/OPL
[2]
http://fedoraproject.org/wiki/WikiLicenseTalk
[3]
http://fedoraproject.org/wiki/Infrastructure/AccountSystem
[4]
http://fedoraproject.org/wiki/UnlicensedGroup
[5]
http://fedoraproject.org/wiki/Legal
--
Patrick "The N-Man" Barnes
nman64(a)n-man.com
http://www.n-man.com/
--
Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/
18 years, 2 months
Relicensing of Fedora Jargon Buster
by Paul W. Frields
Good day Dave,
I hope this email finds you doing well. I am writing to you because the
Fedora Documentation Project is working on a relicensing of our
materials through the Open Publication License v1.0[1]. This licensing
is to cover all the documentation we've produced, as well as the Fedora
Project Wiki[2] and new contributions from other entities. We're very
excited about this move, since the OPL is a less restrictive license
than the GNU FDL, and further it will give us an opportunity to
collaborate with a wider community of content authors[3].
Therefore, I'm writing to you to have your approval to relicense the
Jargon Buster, which, although it has continued to evolve over the past
year or so, is still based on your original contribution. Any
relicensing depends upon the approval of all the authors. Tammy Fox and
I have both contributed to the document over the last year or so, and
our contributions are covered by a licensing agreement. Your work on
the Jargon Buster predates our use of this licensing agreement, thus
this email.
Since I began maintaining that document, a number of users have
contributed useful suggestions, and more importantly, they've found it
very useful. Your approval of the new license will help keep this
document vital and available to the Fedora community.
If you agree to relicense (or dual-license) this work under to OPL, all
you need to do is respond to this email, preferably with a
PGP/GPG-signed email, which would authenticate your approval. In case
you're no longer subscribed to fedora-docs-list(a)redhat.com, you can
simply respond to me if you prefer.
We are trying to complete any CVS (re-)licensing by 22 February[4], so
if you're able to respond by then, it would be greatly appreciated.
Thank you very much for your consideration and your contributions, and
continued best wishes.
= = =
[1] http://www.opencontent.org/openpub/
[2] http://fedoraproject.org/wiki/
[3] http://fedoraproject.org/wiki/DocsProject/Licensing/FAQ
[4] http://fedoraproject.org/wiki/DocsProject/Licensing/Schedule
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
18 years, 2 months
