Bug 754340 - Please handle <graphic> like <imagedata>
Summary: Please handle <graphic> like <imagedata>
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Publican
Classification: Community
Component: publican
Version: 2.8
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: 3.0
Assignee: Jeff Fearn 🐞
QA Contact: Ruediger Landmann
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-16 08:09 UTC by Raphaël Hertzog
Modified: 2012-10-31 03:11 UTC (History)
2 users (show)

Fixed In Version: 3.0.0
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-10-31 03:11:47 UTC


Attachments (Terms of Use)
Patch to recognize <graphic> like <imagedata> (578 bytes, application/octet-stream)
2011-11-16 08:09 UTC, Raphaël Hertzog
no flags Details

Description Raphaël Hertzog 2011-11-16 08:09:43 UTC
Created attachment 533927 [details]
Patch to recognize <graphic> like <imagedata>

<imagedata> is not the only way to include images in a document, there's also <graphic>. It would be nice to support <graphic> too. I attach a patch which tells publican to deal with it in the same way. Seems to work here.

BTW I noticed something odd while reading that part of the code:

                            my $max_width
                                = $self->{publican}->param('max_image_width')
                                || 10000;
                            my $set_width = $node->attr('width') || 0;
                            $set_width =~ s/[^\d]//g;

Ok max_width is 444, and set_width is the custom width if any.

                            if ( $set_width == 444 ) {
                                $node->attr( 'width', undef );
                                $set_width = 0;
                            }
We drop the attribute if the user set a custom width of 444. I don't see why, it could make sense to force a width of 444 if the user changed its max_image_width. But why not, it does not hurt.

                            # Do not override user settings
                            if ($set_width == 0) {
                                $max_width = $set_width
                                    if ( $set_width
                                    && $set_width < $max_width );

Here it gets messy... we test $set_width == 0 so we know it's zero and we know that the test "if ($set_width && ...)" will fail, so this line is never executed. Maybe you wanted that line in the previous test ($set_width == 444) so that the max_width is reduced accordingly to the user specified size.

Comment 1 Jeff Fearn 🐞 2011-11-16 23:05:16 UTC
Added patch, added extra rules to XmlClean to ensure short cut tagging applies when required.

Applied fixe to branches/publican-2x and trunk.

Committed revision 1950.

FYI the max_width code no longer exists in publican-2x or trunk, since we are moving away from FOP. It only existed to overcome FOP limitations.

Comment 2 Jeff Fearn 🐞 2011-11-16 23:37:05 UTC
oops, removed change from trunk as Publican 3 will use DocBook 5 and graphic has been discarded in DocBook 5.

Change still applied to branches/publican-2x.

Comment 3 Jeff Fearn 🐞 2012-04-25 22:46:39 UTC
The fix will apply in 3.0 since we changed DocBook5 to be a tech preview.

Comment 4 Rebecca Newton 2012-05-04 03:55:05 UTC
Confirmed, <imageobject> and <graphic> render the same.

Comment 5 Jared MORGAN 2012-05-04 04:05:06 UTC
OS: Fedora 16

Publican Version: publican-3.0-0.fc16.t168.src.rpm

Remarks:

double-confirmed.

<graphic fileref="image.svg" /> results in graphic displaying correctly.


Note You need to log in before you can comment on or make changes to this bug.