Re: FO to RTF

2002-07-26 Thread Christopher Scott

> RTF is the format of yesterday: better generate MicroSoft Office XML or
Open
> Office XML.

I agree.  I very much dislike RTF as a markup language.  It is cumbersome,
limited, verbose, awkward and terribly outdated.  But RTF is a widely used
standard, whose format is recognized by many lagacy programs.  So the trend
towards XSL:FO becomes much easier if it can be converted to be displayed to
whichever format is most convenient.  For many users that is RTF.  In the
future when/if Microsoft XML becomes standard we can focus on that target.

~Chris Scott

P.S.   I can't even work with Microsoft XML yet, we are still using office
97 and it works just fine.  Is there a compelling reason to upgrade?  Is
microsoft XML an open standard?

- Original Message -
From: J.U. Anderegg <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 26, 2002 2:05 PM
Subject: AW: FO to RTF


> Document formats can be layered very roughly like this:
>
> 1. Structured documents: marked up, tagged CONTENT - document elements
like
> "heading", "index entry" and even "customer address" in a specific
> application:
> - presentation, pagination controlled by style sheets/macros, perhaps
> depending on output device/target
> - examples: HTML, Word with templates
>
> 2. Document formats controlling pagination
> - examples: WordPad, XSL:FO
>
> 3. Device dependent, paginated output streams
> - examples: PCL, PostScript
>
> An other view is: revisable vs. final formats
>
> RTF at layer 1) and 2): a text generator outputs RTF. A transform from XML
> data can be implemented with XSLT. A conversion from XSL:FO might be
> realized at layer 2), but probably fail because of incompatible
> concepts/details.
>
> RTF is the format of yesterday: better generate MicroSoft Office XML or
Open
> Office XML.
> ___
>
> PDF Java Viewer: who can do much better than Adobe? If no Acrobat Reader
is
> available, output PostScript and use GhostView instead of AWT.
>
>
>
> Hansuli Anderegg
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>


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




RE: Black images

2002-07-26 Thread Darrel Riekhof

We found the same thing.  We also found that images with ICC Profiles display 
correctly in FOP 0.20.2, but appear as black boxes in FOP 0.20.3 and 0.20.4.

Anyone know what happened between .2 and .3 that would break this?

Is there a way to strip out the ICC Profile of an image at runtime?  Our users are not 
terribly technical, asking them to not upload images with ICC Profiles may be a little 
too much for them.

Darrel

-Original Message-
From: Northrop, Jeff (REPP-Heinemann)
[mailto:[EMAIL PROTECTED]]
Sent: Friday, July 26, 2002 4:51 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Black images


I've experienced similar problems. I've found if you remove the option for
"ICC Profile:" in the "Save As" dialog the image will render properly in the
PDF. I assume this option adds some data to the jpg resulting in the display
problem not only with FOP and PDFs but I've had problems in the past with
other applications as well.

Jeff

-Original Message-
From: "Buchtík, Michal" [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 26, 2002 1:41 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Black images


This problem occurs when i save the jpg image in Photoshop (i use version
5.0). When i convert it with ACDSee (for example), the problem is resolved.

But I don't know, where's the problem in FOP+Photoshop JPGs.

Michal

-Original Message-
From: Darrel Riekhof [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 26, 2002 12:16 AM
To: [EMAIL PROTECTED]
Subject: Black images


Some images, when FOP embeds them in the PDF, show up as all black
rectangles.  The size of the image is correct.  However, this only occurs if
you are using 16 bit color or higher.  If you lower the color res down to
256 colors, then images always show up in the pdf in acrobat reader.  Client
is Win2000, Acrobat Reader 5, Fop server process is running on red hat linux
7.2 server, fop 2.0.3.

I think this behavior only started happening in FOP 2.0.3, but I'm not
totally sure about this.  I can't figure out if it is an acrobat or fop
thing.  Is this a known issue with FOP?  Anyone found a work-around for
this?

Darrel

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

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


**
This message is intended only for the use of the 
Addressee and may contain information that is 
PRIVILEGED and CONFIDENTIAL. If you are not the
intended recipient, dissemination of this communication is 
prohibited. If you have received this communication in 
error, please erase all copies of the message 
and its attachments and notify us immediately.

REPP-Greenwood Publishing Group

Network Administration @ 603-431-7894
**


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


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




Re: [PDF Viewer] Utility request

2002-07-26 Thread Nicola Ken Barozzi

Ralph LaChance wrote:
> At 12:46 PM 7/25/02, you wrote:
> 
>> After seeing the OutOfMemoryError, the AWT renderer is 
>> causing, why
>> don't thinking of providing a PDF viewer in the FOP itself. I think, this
>> will be useful so much. I don't think people couldn't have ever thought
>> about it, but is it diffucult to do so?
>>I feel, FOP is very much useful with the PDF viewer. What do
>> others say?
> 
> 
> Seems to me it might be a lot simpler to fix the awt viewer...
> 
> Also, oddly enough doing a viewer against pdf is rather tricky -
> Adobe put an un-supported java-bean on their web site, but it
> is buggy and hasn't been updated in 2 or so years. The only
> commercial pkg (a toolset; some assembly required) I know
> of probably would pose a licensing challenge (understatement)

Anyone contacted Adobe to see if they wanna opensource it?

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
 - verba volant, scripta manent -
(discussions get forgotten, just code remains)
-


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




Re: [PDF Viewer] Utility request

2002-07-26 Thread Mark Malone

Folks,
Excuse my ignorance but is the pdf viewer everyone is talking about 
provided already by Adobe on a huge number of platforms and called 
acrobat reader?  Or is it something else that is being requested?   
Also, pdf file reading is built into MacOS X as is pdf generation via 
native print to file output options.  What am I missing?

-M

On Friday, July 26, 2002, at 05:16  AM, Ralph LaChance wrote:

> At 05:24 AM 7/26/02, Ramana wrote:
>> But, how much worth is a creator, without a viewer. In 90% of the
>> applications the needs come to launch the viewer to be part of the
>> application. No user prefers the print the PDF outside and again open 
>> the
>> Acrobat Reader to see it. This lessens the competitiveness of the 
>> product.
>> FOP beautifully caters to the creation of PDF, but a viewer is very 
>> much
>> worthy and I'm sure the FOP with a viewer definitely strikes.
>>
>> Excuse me, If I'm more user conscious...
>
> Strong statements. I suspect there are at least one or two folks on this
> list who might consider ~them~selves quite "user conscious," too.
>
> Perhaps you'd find that toning down the rhetoric might be a tad 
> helpful...  ;-)
>
>
>
> ' Best,
> -Ralph LaChance
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>


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




Re: CTM - e (tx) and f (ty) divided by 1000

2002-07-26 Thread Kevin O'Neill



> > My quick solution was to add a method toPDFArray() that does what the
> > current toArray() does and update toArray() not to do the division and
> > updated the call in startVParea().
> 
> The toArray() method gets the proper value in terms of points so it is
> not really pdf specific. The values we normally use for the area tree
> are in millipoints.
> Maybe we could return an AffineTransform with the point values, and the
> toArray can return the stored values, ie. without dividing by 1000.

Ok, so the millipoints conversion is specific to the xsl:fo to pdf
conversion, the fo tree being in millipoints (correct me if I'm wrong).

I tried using affine transforms, but my transformations where horribly
sheared.

> > I think a better solution would be to create a helper class in
> > org.apache.fop.render.pdf that does the toPDF functions and remove the
> > knowledge of the pdf rendering requirements from org.apache.fop.area.CTM
> > If this seems like to right way to go I'll create some patches for this.
> 
> Yes, the pdf specific code should probably be somewhere pdf specific.

I'll create a couple of patches :)

-k.


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