Re: User Agent

[Keiron Liddle]

On Wed, 2002-11-27 at 19:19, Oleg Tkachenko wrote:
> > There could be two ways to set these values. From the command line we
> > want the config file to set values and when embedding they could extend
> > the user agent to set the values.
> And what about the third one - set config file when embedding? That might be 
> convenient too.

Config file or config data (eg. in cocoon sitemap, the data is in xml
under the fop serializer which cocoon converts to config data).

Yes, the other two make it possible.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 7259] - Additional space generated after inline on PDF Renderer

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7259

Additional space generated after inline on PDF Renderer

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|VERIFIED|CLOSED

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 7259] - Additional space generated after inline on PDF Renderer

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7259

Additional space generated after inline on PDF Renderer

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-28 06:29 ---
Verified the problem does not occur in 0.20.4

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Still on for freeze deadline?

[Peter B. West]

Jeremias Maerki wrote:

Moving around directories on the server so we don't lose history on
files. See my proposal on directory structure reorganization, ex.
moveing src/org to src/java/org.

On 27.11.2002 16:19:26 Peter B. West wrote:


Jeremias Maerki wrote:


BTW: Anybody around with experience in CVS surgery???



Not really, but what do you want to do?


Jeremias,

Look at Sections 7.4 and 7.5 of the Per Cederqvist et al paper.  From 
that, I would say that the easiest and safest thing is simply move the 
files.  When you move them, make sure the descriptive next of the (now) 
new file contains a loud note of the file's original location.  Mind 
you, I haven't experimented with the descriptive text of a new file in 
CVS, as opposed to RCS, so I can't say that it work the same way.

Make sure you tag the tree before and after, and make sure no-one else 
is trying to do commits while this is going on.

The above approach has no special dangers, and allows the complete tree 
of previous releases to be recovered.  The history (if the descriptive 
text is working, and displays normally) will tel the enquirer where to 
look for the prior history of the file.

It's certainly inconvenient for someone who wants to track down the 
history, but it protects the primary requirement - the ability to fully 
recover previous releases.

Peter
--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: regarding properties

[Peter B. West]

sri vela wrote:

Hi 
thanks for your immediate response. i am thinking of
implemention table-layout="auto" property. you said
that the new properties implementation requires some
kind of redesign of the code bade. May i know what
properties can i implement now which are not depending
on the redesign so that i will work on them first.how
about keep properties?

Sri,

You have picked just about the toughest layout problem of them all.  If 
you want to work on this one, you have to get involved in redesign, with 
either the HEAD line or alt.design.

Peter
--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: need help regarding properties implementions

[Peter B. West]

Oleg Tkachenko wrote:

sri vela wrote:


I would like to know what are the properties that
people are working on.


I don't think the list exist. Almost all unimplemented properties 
require some kind of redesign of the code base, and that's exactly what 
we are working on.

The reason why i am asking is
because i am also planning to implement some
properties.


Everybody's invited, it's open source. Which properties are you talking 
about?


Sri,

There is a near complete complement of properties in Alt-Design.  Only 
some of the shorthands remain.  The application of properties to layout 
is another story.  Two approaches have been mooted.  1) Smart 
properties, in which the properties are contain the logic for applying 
them. 2) Dumb properties, in which the properties are, after parsing, 
simply a name/value pair, and it is up to the FOs, or whatever lays out 
the FOs, to apply those values.  Alt-Design takes the second view.

Peter
--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Patch posted for bug #8778.

[Rhett Aultman]

I posted a patch for bug #8778 into bugzilla.  I hope I did the diffing right...first 
time and all.  The fix corrects bug #8778 (and possibly one other, but I'm not sure) 
and does not affect the examples (as far as I can tell).

--
J. Rhett Aultman
Business Technology Solutions
FCCI Insurance Group


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Still on for freeze deadline?

[Victor Mote]

Jeremias Maerki wrote:

> Moving around directories on the server so we don't lose history on
> files. See my proposal on directory structure reorganization, ex.
> moveing src/org to src/java/org.
>
> On 27.11.2002 16:19:26 Peter B. West wrote:
> > Jeremias Maerki wrote:
> > >
> > > BTW: Anybody around with experience in CVS surgery???
> > >
> >
> > Not really, but what do you want to do?

The only repository work I have done had to do with getting some RCS file
safely into one, which was a mild form of hacking. The O'Reilly book "CVS
Pocket Reference" has a section (p. 26) on "Hacking the Repository". It
urges extreme caution, backups, etc., then suggests simply moving the
directories around in the repository. It also warns that this is dangerous
when there are active sandboxes. Cederqvist also seems to indicate that a
simple move will work, Sec. 7.4.2, and points out that this will basically
break any checkouts of previous tags. In other words, trying to check out an
old tag will put the files in the /new/ location, which is inconsistent with
the references to it in other files.

If you're going to do this, it makes sense to do it while the release is
frozen, as everyone will want to get a new sandbox after the fact anyway.

Victor Mote


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Still on for freeze deadline?

[Jeremias Maerki]

Moving around directories on the server so we don't lose history on
files. See my proposal on directory structure reorganization, ex.
moveing src/org to src/java/org.

On 27.11.2002 16:19:26 Peter B. West wrote:
> Jeremias Maerki wrote:
> > 
> > BTW: Anybody around with experience in CVS surgery???
> > 
> 
> Not really, but what do you want to do?


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: User Agent

[Oleg Tkachenko]

Keiron Liddle wrote:


What is the convention behind UserAgent class? afaiu, the class should 
provide default values for all user-agent-related properties, which are 
overridable through the configuration file.


There could be two ways to set these values. From the command line we
want the config file to set values and when embedding they could extend
the user agent to set the values.

And what about the third one - set config file when embedding? That might be 
convenient too.

So, if I want to add auto values for page-height and page-width, how 
should I do it?


So an "auto" value should be determined by the user agent, right?

I think so. Spec says they should be "determined, in the case of continuous 
media, from the size of the User Agent window, otherwise from the size of the 
media." At least Antenna exposes these as user agent parameters.

Then just add the methods to the user agent.

Do you have any ideas of how to better specify the user agent config
data?

Well, I've been thinking about a kind of JavaBeans naming convention, when for 
each propery there is setter and getter and config file parser then could 
populate UserAgent through reflection API. But that might add unnecessary 
complexity + reflection is not so fast, so another alternative could be usual 
hash table and a propery getter may then check hashtable key first and if it's 
not exists return default value:
public int getAutoPageHeigh() {
	String val;
	if ( (val = (String)hashtable.get(AUTO_PAGE_HEIGHT_KEY)) != null)
		return String.parseInt(val);
	else
		return DEFAULT_AUTO_PAGE_HEIGHT;
}
But actually number of UserAgent properties is pretty well limited and it's 
not going to extend, so its processing may be even less generic.

--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

regarding properties

[sri vela]

Hi 
thanks for your immediate response. i am thinking of
implemention table-layout="auto" property. you said
that the new properties implementation requires some
kind of redesign of the code bade. May i know what
properties can i implement now which are not depending
on the redesign so that i will work on them first.how
about keep properties?

Thank you very much
Sri

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: need help regarding properties implementions

[Oleg Tkachenko]

sri vela wrote:


I would like to know what are the properties that
people are working on.

I don't think the list exist. Almost all unimplemented properties require some 
kind of redesign of the code base, and that's exactly what we are working on.

The reason why i am asking is
because i am also planning to implement some
properties.

Everybody's invited, it's open source. Which properties are you talking about?

--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

need help regarding properties implementions

[sri vela]

Hi all,
I would like to know what are the properties that
people are working on. can i get the list of
properties that people are working on right now. any
body is maintaining the list. If so where can i see
that list of properties. The reason why i am asking is
because i am also planning to implement some
properties.

Thank you very much
Sri

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Servlet, contrib stuff and tutorial

[Oleg Tkachenko]

Jeremias Maerki wrote:


Oleg and I wonder what we should do with the fact that the FOP servlet
exists in docs/examples/embedding and contrib/servlet. Joerg seems to
have some ideas about this, so I hope he tells us when he's back from
holidays. But the other's opinion is also wanted here. IMO the servlet
should always be built from the sources now in contrib. The
docs/examples/embedding stuff should be deleted. Joerg thinks
differently, I think.

The question is actually whether contrib/servlet stuff is included into the 
distribution. If so, I don't see any reason to duplicate java code and war.
Just need to change documentation and probably leave explanatory readme file 
in the examples/embedding directory.
If not, the duplication seems reasonable.
Looking to the archive [1] I see Joerg said "Contrib/servlet is not 
distributed, instead, the Java source and a war file is in 
docs/examples/embedding." I believe we should wait till Joerg is back to 
clarify that.

I've started a "How to use FOP in Java/Usage patterns" tutorial
yesterday. When finished it will consist of some Java sources, a few XML
files (XMLs, FOs, XSLTs) and documentation in XML format.

That's great.


IMO the following things should be done:
- move the hyph directory to src/hyph

+1

- move the FO schema to src/foschema

-1 Is it really source? I believe that's more documentation/test stuff.


- move src/org to src/java/org

This can confuse people, as it may look like java.org.* packages. Such ones do 
exist and are reserved to SUN afair.

- move contrib/servlet to examples/servlet
- move contrib/plan to examples/plan
- move contrib/mathml to examples/mathml

+1


- move conf to src/conf

-1 it's not a source actually.


- remove docs/examples/embedding
- move docs/examples to examples/fo

+1

- place the tutorial in examples/tutorial or tutorial (don't know yet)

docs/tutorial ?

[1] http://marc.theaimsgroup.com/?l=fop-dev&m=103196215022751&w=2
--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Still on for freeze deadline?

[Oleg Tkachenko]

Rhett Aultman wrote:


I have to go away for Thanksgiving to a
town that doesn't have any Internet access of any kind (meaning I can't
make the uploads).

Are such places still exist? :)

--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: org.apache.fop.viewer.PreviewDialog

[Oleg Tkachenko]

IvanLatysh wrote:


Yes, reload method will call "starter.run();"
And page in the renderer will be altered with a new one.
Try to comment "starter.run();" in PreviewDialog and see what happened.

But why? starter.run() runs clean formatting, isn't it what you want?


Scale image are mandatory. Without scaling all working Ok.
I could send you mine "previewPanel.java"

Sure. Mail it to me privately. Or alternatively file it to bugzilla as feature 
request. But explain first, what's wrong with starter.run() ?

--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Alt-Design status: XML handling

[Oleg Tkachenko]

Rhett Aultman wrote:

  But, a

pull model can be grafted onto a push model by implementing what amounts to
a specialized buffer of the pushed data that accepts pull queries...no?

Yes, another alternative is additional thread with the same duties. See
Aleksander Slominski's parer: 
http://www.extreme.indiana.edu/xgws/papers/xml_push_pull/node3.html

--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Still on for freeze deadline?

[Peter B. West]

Jeremias Maerki wrote:


BTW: Anybody around with experience in CVS surgery???



Not really, but what do you want to do?

Peter
--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6638] - [PATCH] Enable auto portrait/landscape on PCL Renderer

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6638

[PATCH] Enable auto portrait/landscape on PCL Renderer

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-27 15:08 ---
Looks good on my Brother HL-1250.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 14248] - 51-page FO example, could be added to the samples

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14248

51-page FO example, could be added to the samples





--- Additional Comments From [EMAIL PROTECTED]  2002-11-27 15:02 ---
I noticed this example has a fo:footnote in a static region which is invalid.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-fop/src/org/apache/fop/layoutmgr TextLayoutManager.java

[keiron]

keiron  2002/11/27 06:59:53

  Modified:src/org/apache/fop/layoutmgr TextLayoutManager.java
  Log:
  convert " " into a Space inline
  
  Revision  ChangesPath
  1.17  +13 -9 xml-fop/src/org/apache/fop/layoutmgr/TextLayoutManager.java
  
  Index: TextLayoutManager.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/layoutmgr/TextLayoutManager.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- TextLayoutManager.java13 Nov 2002 10:25:48 -  1.16
  +++ TextLayoutManager.java27 Nov 2002 14:59:52 -  1.17
  @@ -164,8 +164,8 @@
   if (prevPos != null) {
   // ASSERT (prevPos.getLM() == this)
   if (prevPos.getLM() != this) {
  -//log.error(
  -//  "TextLayoutManager.resetPosition: " + "LM mismatch!!!");
  +getLogger().error(
  +  "TextLayoutManager.resetPosition: " + "LM mismatch!!!");
   }
   LeafPosition tbp = (LeafPosition) prevPos;
   AreaInfo ai =
  @@ -477,23 +477,27 @@
   //" total=" + iAdjust);
   
   // Make an area containing all characters between start and end.
  -Word word = null;
  +InlineArea word = null;
   int adjust = 0;
   // ingnore newline character
   if(chars[ai.iBreakIndex - 1] == NEWLINE) {
   adjust = 1;
   }
   String str = new String(chars, iStart, ai.iBreakIndex - iStart - adjust);
  -//if(!"".equals(str.trim())) {
  -word = createWord(
  +if(" ".equals(str)) {
  +word = new Space();
  +word.setWidth(ai.ipdArea.opt + iAdjust);
  +} else  {
  +Word w = createWord(
 str,
 ai.ipdArea.opt + iAdjust, context.getBaseline());
   if (iWScount > 0) {
  -//log.error("Adjustment per word-space= " +
  +//getLogger().error("Adjustment per word-space= " +
   //   iAdjust / iWScount);
  -word.setWSadjust(iAdjust / iWScount);
  +w.setWSadjust(iAdjust / iWScount);
   }
  -//}
  +word = w;
  +}
   if ((chars[iStart] == SPACE || chars[iStart] == NBSPACE) &&
   context.getLeadingSpace().hasSpaces()) {
   context.getLeadingSpace().addSpace(halfWS);
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Still on for freeze deadline?

[Jeremias Maerki]

From your original plan we still have to finish the documentation stuff,
right? Maybe we can also include the reorganized directory layout. But
that will take another week or two, I guess. Especially because I'd like
to leave Jörg a chance to voice his opinion. Until then I will be able
to include my tutorial.

BTW: Anybody around with experience in CVS surgery???

On 27.11.2002 12:30:36 Christian Geisert wrote:
> Rhett Aultman wrote:
>  > Guys,
>  >
>  > I finally got myself out from under my grad school apps long
>  > enough to employ a patch that helps nerf certain kinds of
>  > infinite loops in the maintenance branch of FOP.
>  > I'd like to see it go into the final release of the maintenance
> 
> [..]
> 
>  > Is the Thanksgiving deadline for patches and whatnot strictly
>  > in effect? If so, I'll see about hauling buns to get this together.
> 
> Huh? Never heard of a Thanksgiving deadline.
> I don't even know when Thanksgiving is .. asking Google .. ah
> it's on the fourth Thursday in November (i.e. tomorrow).
> 
> My plan was to apply one last small patch later today and
> then ask for a freeze.
> As much as I would like to finish this release the patch
> should IMHO make it into this last maintenance release.
> Other opinions?



Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Background information about using unicode characters

[Oleg Tkachenko]

Tore Engvig wrote:


This has the drawback that searching or cut'n' paste fra the PDF document
won't work (e.g. see bug #5335). To fix this, a ToUnicode mapping should be
created such that the characters in the PDF document are unicode (UTF-16
encoded) and a mapping between unicode and glyph index is embedded with the
font. The reason why this wasn't implemented to begin with was that it
wasn't documented very well in the PDF spec. Experimenting with different
settings was hard (development on a slow computer implied a very long and
frustrating round-trip)  and error messages from Acrobat reader wasn't very
cooperative :)
Since then Adobe has published a tutorial and howto for creating ToUnicode
maps:
http://partners.adobe.com/asn/developer/pdfs/tn/5411.ToUnicode.pdf
So it should be easier to create now.


Good answer, Tore! I saved link to your post in bug #5335 if you don't mind.

--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 5335] - Text with embedded CID fonts not retrievable from pdf

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5335

Text with embedded CID fonts not retrievable from pdf





--- Additional Comments From [EMAIL PROTECTED]  2002-11-27 14:23 ---
See http://marc.theaimsgroup.com/?l=fop-dev&m=103839237726705&w=2

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Current CVS version won't build

[Thilo Schwidurski]

- Original Message -
From: "Thilo Schwidurski" <[EMAIL PROTECTED]>
>
> Well, after checking out the 0.20.5 branch I still face the exact same
> problems.

And this is (most likely) the reason: my path to the build directory
constains whitespace characters (a fragment of it is the W2K "Dokumente und
Einstellungen"), so the URI constructor throws a MalformedURIException. If I
had posted my complete path instead of "\[...]\xml-fop" you probably would
have been able to tell me earlier. Dammit. So much about red herrings... :-/

The problem is, that the "Path contains invalid character: " message which
the MalformedURIException gets initialized with is not transported to the
user, but the (less specific) message "no protocol: ".

Anyway, my resolution for this problem is clear now... ;-)

Bye,
Thilo.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Still on for freeze deadline?

[Rhett Aultman]

Response below.

-Original Message- 
From: Christian Geisert [mailto:[EMAIL PROTECTED]] 
Sent: Wed 11/27/2002 6:30 AM 
To: [EMAIL PROTECTED] 
Cc: 
Subject: Re: Still on for freeze deadline?



>>Huh? Never heard of a Thanksgiving deadline.
I don't even know when Thanksgiving is .. asking Google .. ah
it's on the fourth Thursday in November (i.e. tomorrow).<<


I could have sworn we'd set a deadline like that.  I'd check the archives, but 
I'm out the door and off to work at the moment. 


>>My plan was to apply one last small patch later today and
then ask for a freeze.
As much as I would like to finish this release the patch
should IMHO make it into this last maintenance release.<<
 
Admittedly, my patch is tiny and probably only addresses bug #8778, so maybe 
we can do without it.  I'll make a best effort to get it wrapped up today either way.

 


<>-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Still on for freeze deadline?

[Ralph LaChance]

At 06:30 AM 11/27/02, you wrote:

I don't even know when Thanksgiving is .. asking Google .. ah
it's on the fourth Thursday in November (i.e. tomorrow).


Well you might ask.

It is different in Canada (one month earlier) and then there
are the wags who suggest that July 4th, the anniversary
of America's independence is called Thanksgiving day
in the UK   ;-)



' Best,
-Ralph LaChance



In theory, there is no difference between
theory and practice, but in practice there is.

(Someone wrote that, but I don't know who.)




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Still on for freeze deadline?

[Christian Geisert]

Rhett Aultman wrote:
> Guys,
>
> I finally got myself out from under my grad school apps long
> enough to employ a patch that helps nerf certain kinds of
> infinite loops in the maintenance branch of FOP.
> I'd like to see it go into the final release of the maintenance

[..]

> Is the Thanksgiving deadline for patches and whatnot strictly
> in effect? If so, I'll see about hauling buns to get this together.

Huh? Never heard of a Thanksgiving deadline.
I don't even know when Thanksgiving is .. asking Google .. ah
it's on the fourth Thursday in November (i.e. tomorrow).

My plan was to apply one last small patch later today and
then ask for a freeze.
As much as I would like to finish this release the patch
should IMHO make it into this last maintenance release.
Other opinions?

Christian



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Background information about using unicode characters

[Tore Engvig]

[EMAIL PROTECTED] wrote:

> Hi,
>
> I'm using fop 0.20.4 with jdk 1.4 and would like to get some background
> information about how fop embedds unicode character from a true
> type font which
> is not one of the 14 PDF Standard Fonts. I used "Arial Unicode Ms.ttf" to
> embed some asien characters into an pdf document. Based on the
> information from
> the fop homepage I assume that only the needed character, its
> encoding and the
> glyph is embedded into the pdf file to enable the Acrobat Reader to render
> the character correctly.  Is that correct, or are more
> information embedded
> like the whole codepage in which the charater is in? Or which
> information are
> exactly embedded into the pdf file?

For TrueType fonts, only the glyphs used are embedded. When you embed a
truetype font, a new font containing only the glyphs used are created from
the original font and embedded in the pdf document. The embedded font
contains only the minimum needed to be embedded in a pdf document (i.e no
codepage information). The PDF document will then contain indexes to the
glyphs in the font instead of characters using an encoding.

This has the drawback that searching or cut'n' paste fra the PDF document
won't work (e.g. see bug #5335). To fix this, a ToUnicode mapping should be
created such that the characters in the PDF document are unicode (UTF-16
encoded) and a mapping between unicode and glyph index is embedded with the
font. The reason why this wasn't implemented to begin with was that it
wasn't documented very well in the PDF spec. Experimenting with different
settings was hard (development on a slow computer implied a very long and
frustrating round-trip)  and error messages from Acrobat reader wasn't very
cooperative :)
Since then Adobe has published a tutorial and howto for creating ToUnicode
maps:
http://partners.adobe.com/asn/developer/pdfs/tn/5411.ToUnicode.pdf
So it should be easier to create now.

This behavior can be avoided if the -ansi option is included when generating
metrics with TTFReader. If you do, the whole font will be embedded in the
pdf document and characters will be ansi encoded (so, you loose the
possibility to use non-ansi characters) - or more correctly: WinAnsi encoded
as specified in the PDF spec.

For PostScript fonts the behavior is different. If you embed a postscript
font, the whole font is always embedded.

> Can I rely on the assumption that the
> pdf file with the embedded font will be displayed correctly
> independingly on
> the
> operating system and the available fonts on which ever computer
> the pdf file
> is trying to be viewed?

Yes. To achieve this, the fontname is scrambled. A prefix is inserted to
make sure that the fontname won't match the fontname of an installed font.
Acrobat reader used to prefer installed fonts rather than embedded fonts
which could cause problems if the user had installed different versions of
the embedded fonts (e.g. fonts which don't have some characters used in the
pdf document, or simply looks different). Acrobat Reader 5.0 has the option
to select whether system installed fonts or document embedded fonts should
be used, so this prefix thing can be removed. However, it's not a huge gain
to remove it. The only case where you gain something is if you merge a lot
of pdf documents that embed the same font. Then Acrobat (fullversion only)
can merge the fonts so you don't embed the same font twice in the same
document.

> Is it possible to create a PDF file with FOP which just describes a
> character by its unicode representation and the corresponding
> glyph to display the
> character is loaded from one of the available fonts from the
> computer where the
> pdf file is viewed? That would be an interesting an valueable feature
> instead of embedding the font file.

You don't have to embed the font. I'm not sure how well this is supported,
but I think that if you use any other encoding than ansi, you're screwed
(because of the lack of ToUnicode maps).

You most probably want to embed the fonts anyway. Real life example
(happened this year): I was generating reports for a huge organization. All
the computers in that organization were supposed to be equal - maintenance
was centralized and all computers were automatically upgraded (and users
were not permitted to install anything). Much effort was spent to have all
computers be equal. No matter the effort, there was 2 different versions of
the Arial font installed on different computers. The newest Arial version
had more glyphs, and most important: The glyphs was bigger! That totally
ruined the reports causing page-breaks where there shouldn't be any,
overflow, etc.

Moral is: always embed the fonts :)


Tore

>
> Thanks a lot for any information to clarify understanding!
>
> Markus
>
>
>
> --
> +++ GMX - Mail, Messaging & more  http://www.gmx.net +++
> NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
>
>
> -
> To 

Re: FOP Servlet, contrib stuff and tutorial

[Bertrand Delacretaz]

On Wednesday 27 November 2002 09:36, Keiron Liddle wrote:
> On Tue, 2002-11-26 at 13:53, Jeremias Maerki wrote:
>. . .
> > Problems that need to be addressed:
> > - All Java sources need to be checked easily before a release (do they
> >   compile, do they work?).
>
> Could ant call help out here? No extra build.sh or build.bat.
>. . .

The ant "ant" task can easily call an external build.xml.

The "cvs" task allows sources to be checked out (but AFAIK requires 
command-line CVS to be installed on Windows systems).

-Bertrand

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: keep propery

[Jeremias Maerki]

The keep properties will be adressed in the redesign. That was one of
the main reasons the redesign was started in the first place. The
support for keep properties on table-rows will stay as it is in the
maintenance branch. The redesign is on its way but we can't tell you a
date when it will be finished. Check the FOP website regularly for the
status of the redesign.

http://xml.apache.org/fop/status.html

On 26.11.2002 22:49:26 sri vela wrote:
> is any one implementing keep properties? If so i need
> some information about keep properties.


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: User Agent

[Keiron Liddle]

On Mon, 2002-11-25 at 20:40, Oleg Tkachenko wrote:
> Hello!
> 
> What is the convention behind UserAgent class? afaiu, the class should 
> provide default values for all user-agent-related properties, which are 
> overridable through the configuration file.

There could be two ways to set these values. From the command line we
want the config file to set values and when embedding they could extend
the user agent to set the values.

> So, if I want to add auto values for page-height and page-width, how 
> should I do it?

So an "auto" value should be determined by the user agent, right?
Then just add the methods to the user agent.

Do you have any ideas of how to better specify the user agent config
data?



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP Servlet, contrib stuff and tutorial

[Keiron Liddle]

On Tue, 2002-11-26 at 13:53, Jeremias Maerki wrote: 
> (Warning: this mail starts slowly and is getting mean at the end...)
> 
> Oleg and I wonder what we should do with the fact that the FOP servlet
> exists in docs/examples/embedding and contrib/servlet. Joerg seems to
> have some ideas about this, so I hope he tells us when he's back from
> holidays. But the other's opinion is also wanted here. IMO the servlet
> should always be built from the sources now in contrib. The
> docs/examples/embedding stuff should be deleted. Joerg thinks
> differently, I think.

I think there should be a requirement that it compiles and works if it will be 
distributed.

> In the trunk we've also got the plan and MathML goodies.
> 
> I've started a "How to use FOP in Java/Usage patterns" tutorial
> yesterday. When finished it will consist of some Java sources, a few XML
> files (XMLs, FOs, XSLTs) and documentation in XML format.

Great idea!

> The question is where's the best location to place all this stuff. It
> would be best if we reorganized the directory structure, especially in
> the context of moving to forrest. Let's take an inventory:
> 
> - basic documentation/website (maint and trunk)
> - FOP servlet
> - MathML extension (trunk only)
> - Plan extension (trunk only)
> - FOP usage tutorial (yet to come)
> - FO schema
> - FO samples (docs/examples/*)
> - Testcases
> - Hyphenation source files
> - Sample config files
> (anything else?)
> 
> Problems that need to be addressed:
> - All Java sources need to be checked easily before a release (do they
>   compile, do they work?).

Could ant call help out here? No extra build.sh or build.bat. 
I'm not sure how/if it can do it but something about calling an external
build.xml?

> - Helpful information has to be easily found.
> - Consistent approach to place files.
> 
> In the past new stuff has been added to the codebase "somehow". This
> should be cleaned up, too, while we're cleaning up the documentation.
> Of course, that will generate a lot of work and probably some
> reshuffling in CVS but will result in a cleaner directory structure. I
> volunteer to do this in both the maint and trunk but I will probably
> need help with CVS surgery if this is needed.
> 
> IMO the following things should be done:
> - move the hyph directory to src/hyph
+1 
> - move the FO schema to src/foschema
+1 
> - move src/org to src/java/org
+1 
> - move conf to src/conf
+1
> - move contrib/servlet to examples/servlet
> - move contrib/plan to examples/plan
> - move contrib/mathml to examples/mathml
> - remove docs/examples/embedding
> - move docs/examples to examples/fo
> - place the tutorial in examples/tutorial or tutorial (don't know yet)

So the examples are: tutorials, fo documents, embedding examples and
extensions. Sounds clearer to be under:
examples/
+1

Another thing I was thinking of. The pdf bookmark extension is a bit
confusing being placed in .../fop/extensions/ because it suggests a
generic extension which it isn't.

The testing will also be needed to move somewhere better I think. It
will have code, fo files, other resources and some way of running tests.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]