DO NOT REPLY [Bug 32528] - 'viewbox' attribute of element handled incorrectly

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32528


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Rendering images wrong size |'viewbox' attribute of 
   ||element handled incorrectly




--- Additional Comments From [EMAIL PROTECTED]  2004-12-04 04:48 ---
It seems the bug is due to the vertical aspect of the svg's viewbox attribute
not being handled correctly.  

The document below demonstrates the problem more clearly.  The second rectangle
drawn here should extend outside of the viewport; however, it's vertical aspect
is still within the view.








http://www.w3.org/1999/XSL/Format";
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
xmlns:svg="http://www.w3.org/2000/svg";>






















Puzzle
Cornerhttp://www.kitfox.com/puzzlecorner












http://www.w3.org/2000/svg"; x="0" y="0" width="190mm" 
height="277mm">







http://www.w3.org/2000/svg"; width="190mm" height="277mm" viewBox="0
0 10 10">







http://www.w3.org/2000/svg"; width="190mm" height="277mm" viewBox="0
0 10 10">












-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32528] New: - Rendering images wrong size

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32528

   Summary: Rendering images wrong size
   Product: Fop
   Version: all
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: major
  Priority: P2
 Component: svg
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I intend to use the file below to create a small book in which the pages are
defined as SVG files.  The FO is intended to provide titles, page numbers, and
bundle things nicely so it can be displayed as a PDF.  Unfortunately, the values
I use for the width and height of  and  seem to
be ignored.  When I transform the below document, there are large gaps both
above and below the image.  

With the current settings, the svg content ought to obscure the header and
footer.  However, the entire SVG has been squashed and leaves large gaps above
and below the image content.  Could someone look at this and tell me if this is
an error in my coding or if it's a bug?

Thanks,

Mark McKay

---




http://www.w3.org/1999/XSL/Format";
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
xmlns:svg="http://www.w3.org/2000/svg";>





















Puzzle
Cornerhttp://www.kitfox.com/puzzlecorner











http://www.w3.org/2000/svg"; width="190mm" height="277mm" viewBox="0
0 10 10">







http://www.w3.org/2000/svg"; width="190mm" height="277mm" viewBox="0
0 10 10">







http://www.w3.org/2000/svg"; width="190mm" height="277mm" viewBox="0
0 10 10">












-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: More questions on line breaking.

[Finn Bock]

1) What is inactiveList doing. Nodes are added but never used.
[Simon]
It contains all feasible breakpoints except those that are still
active, i.e., are still in scope as the start of a line ending at the
currently considered breakpoint. At the end of the loop the active
list only contains nodes pertaining to the end of the paragraph. From
the best one of them the breakpoints of the paragraph are calculated
by tracing back to the beginning through the inactive list.
See the code in LineLM after the comment
// use the chosen node to determine the optimum breakpoints
in the line
bestActiveNode = bestActiveNode.previous;
the previous node is held in the inactive list.
Ok, so it isn't really needed when the algorithm is implemented in java. 
Just by having the previous node linked from within bestActiveNode is 
enough to keep the inactive nodes alive.

So inactiveList can be removed.
regards,
finn

Re: [Bug 32253] - Marker bugs

[Simon Pepping]

Hi,

The NIST test suite has no example of an fo:block within an fo:inline
element. Neither does the XSL spec have an example. Apparently the
construction is not very popular.

I have read through the XSL spec, sections 4.4. Block Areas, 4.5. Line
Areas, 4.6. Inline Areas, and especially 4.7.2. Line building and
4.7.3. Inline building. See esp. items 1, 3, and 5 of the rules for
the partitioning. I believe the following areas should be created:

A block inside another block

Normal text 
  inner block 
normal text.

creates:

Block area -+-- Line area +-- Character areas
|
+-- Block area  +-- possibly Line area etc.
|
+-- Line area +-- Character areas

A block inside an inline inside a block

Normal text 
  inline text 1
inner block 
inline text 2 
normal text.

creates:

Block area -+-- Line area +-- Character areas
| +-- Inline area -- Character areas
|
+-- Line area +-- Inline area -- Block area +-- Line area etc.
|
+-- Line area +-- Inline area -- Character areas
  +-- Character areas

The fo:inline creates three inline areas, one with the text 'inline
text 1', one with the block area, and one with the text 'inline text
2'. The outer block arranges the inline areas from its PCDATA and
those returned by its fo:inline child into lines.

Note also that the inner block area behaves as a child of the inline
area with respect to such traits as the border and the background
traits.

As a conclusion I believe InlineLM must be modified to handle the BPs
returned by a block-area generating child. Perhaps it should wrap them
in a Knuth Box of the appropriate width, or in a new class of Knuth
Element, which LineLM would know that it should be placed on a line of
its own.

Regards, Simon

--
Simon Pepping
home page: http://www.leverkruid.nl

Re: More questions on line breaking.

[Simon Pepping]

On Thu, Dec 02, 2004 at 08:42:30PM +0100, Finn Bock wrote:
> Hi
> 
> Some more questions.
> 
> 1) What is inactiveList doing. Nodes are added but never used.

It contains all feasible breakpoints except those that are still
active, i.e., are still in scope as the start of a line ending at the
currently considered breakpoint. At the end of the loop the active
list only contains nodes pertaining to the end of the paragraph. From
the best one of them the breakpoints of the paragraph are calculated
by tracing back to the beginning through the inactive list.

See the code in LineLM after the comment
// use the chosen node to determine the optimum breakpoints

in the line
bestActiveNode = bestActiveNode.previous;
the previous node is held in the inactive list.

The article with the algorithm was originally published in: Donald
E. Knuth and Michael F. Plass, Breaking Paragraphs into Lines,
Software---Practice and Experience 11 (1981) 1119-1184. It should be
possible to find this journal in academic libraries.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Info on Avalon Framework

[Jeremias Maerki]

On 03.12.2004 15:19:11 Glen Mazza wrote:
> 

I guess that's "fahrenheit", right? Makes 37.0°C. So no big deal, then.
:-)

> It appears we should
> switch from Avalon configuration to Commons
> configuration -- and then drop the Avalon library from
> HEAD.  Thoughts?

-0. I see no reason. Avalon Framework works, is stable and still
maintained. Commons Configuration is more complicated and someone would
have to volunteer to do the conversion. It adds a runtime dependency on
commons-collections. Furthermore, it's unclear to me if this would
also introduce runtime dependencies on commons-digester and
commons-beanutils. 


Jeremias Maerki

Re: Info on Avalon Framework

[Glen Mazza]

 It appears we should
switch from Avalon configuration to Commons
configuration -- and then drop the Avalon library from
HEAD.  Thoughts?

Thanks,
Glen


--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Gang,
> 
> you may have heard about what happened in
> Avalon-land. Looks like the
> project has failed from a community POV. So, just
> for those who don't
> know already, Avalon Framework which we use in FOP
> has been transferred
> over to the Avalon Excalibur project
> (http://excalibur.apache.org/).
> 
> The source code is here:
>
https://svn.apache.org/repos/asf/excalibur/trunk/framework/
> 
> The announcement:
>
http://www.mail-archive.com/users@avalon.apache.org/msg05033.html
> 
> My impression is that the package will remain active
> and maintained this
> way, so actually this doesn't change anything for
> us.
> 
> Jeremias Maerki
> 
> 

DO NOT REPLY [Bug 17521] - Fonts in 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://issues.apache.org/bugzilla/show_bug.cgi?id=17521


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
   ||forum.de
 OS/Version||All




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.