This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 754340 - Please handle <graphic> like <imagedata>
Please handle <graphic> like <imagedata>
Status: CLOSED CURRENTRELEASE
Product: Publican
Classification: Community
Component: publican (Show other bugs)
2.8
Unspecified Unspecified
unspecified Severity unspecified
: 3.0
: ---
Assigned To: Jeff Fearn
Ruediger Landmann
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-16 03:09 EST by Raphaël Hertzog
Modified: 2012-10-30 23:11 EDT (History)
2 users (show)

See Also:
Fixed In Version: 3.0.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-30 23:11:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Raphaël Hertzog 2011-11-16 03:09:43 EST
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 18:05:16 EST
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 18:37:05 EST
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 18:46:39 EDT
The fix will apply in 3.0 since we changed DocBook5 to be a tech preview.
Comment 4 Rebecca Newton 2012-05-03 23:55:05 EDT
Confirmed, <imageobject> and <graphic> render the same.
Comment 5 Jared MORGAN 2012-05-04 00:05:06 EDT
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.