Request for suggestion - Images

[berard]

I'm curious to see if anyone has ideas on how best to handle the following
scenario from an authoring UI perspective.

We currently have several documents that we author in XML then render to
PDF (using an external engine). These documents contain images at set
locations, and are embedded in the XML as native SVG, which are processed
by XSL:FO. Due to the nature of SVG, the images themselves are somewhat
large, and so we've been inserting them into the "final" XML after all copy
is complete. This works out fairly well for new documents, but gets a bit
cumbersome when managing subsequent editions (eg: remove and reinsert, or
leave in, but instruct the authors to ignore the SVG markup)

One approach we have used in the past is to put in reference tags that our
build process can interpret and replace. This would be something like:
<svg db_id="12345">Caring for your cast</svg>
The assembly process would then take this tag and replace it with the
actual SVG markup stored in our CMS.

This would work fine, but it's not very visual for the author to use as a
reference. It would be better if we could have some kind of inline
thumbnail, but I'm not sure if that's possible without embedding some kind
of clunky ActiveX control.

Has anyone worked with images in this way, and if so, have any suggestions
on implementation?

Thanks,
Keith Berard
Milliman Care Guidelines

[GregoryMackenzi]

Hi Keith,



I use SGML but if I wanted to do something like this I'd use a small
jpeg and entity and catalog references (respectively below) to refer to
the graphic. Something like:



NDATA jpeg>



PUBLIC "-// ABC-DEF::NAME //NONSGML AIRSHIP GRAPHIC//EN"

"mygraphicspath\AIRSHIP-RevA.jpg"



Then I'd probably change the entity reference and catalog with a simple
text editor to point to the vector graphic prior to processing:



NDATA eps>



PUBLIC "-// ABC-DEF::NAME //NONSGML AIRSHIP GRAPHIC//EN"

"mygraphicspath\AIRSHIP-RevA.eps"



You'd need a revision system, that is a numbering system to keep track
of the current version of the graphic.



This might be a little clunky, and involves some manual editing. Someone
wiser than I may have a better idea.



Greg

[ebenton]

You could possible try using the filename method for graphics and not graphic entities. In the editing environment you could have no APTGRPATH environment variable.
The rendering process could be done from a batch file that could set the APTGRPATH variable to wherever your graphics are located.

[thendricks]

I think the problem here is the introduction of the CMS.

Could you follow the information below to in regards to creating a thumbnail in a shared location and then have your users map to that file versus the svg? Then, when publishing, mod your XSL-FO to parse the file name to remove the extension if needed thus redirecting to the CMS copy.

[berard]

Thanks for all of the suggestions thus far. I should note that I'm not
really concerned about any type of conversion (whether it be to jpg, or to
convert entities to SVG; that is a simple replace in our build process)

My concern with entities is that I will need to somehow first insert the
actual entity into the XML prior to being able to use the entityref, though
I'm sure I could figure out some way to do this with ACL/Java. Assuming
this is possible, I'm not sure what I would need to modify in my FOSI to
get the image to appear inline within content.

One thing I've been playing around with is defining a XuiControl element in
the <specials> section of my dcf. This would allow me to both embed the
image reference, as well as use a tag, which would allow for ACL to insert
at caret.

I'll keep you posted as to what I figure out. (or don't figure out, heh)

keith

On Thu, Sep 20, 2012 at 2:00 PM, Hendricks Trevor <
-> wrote:

> I think the problem here is the introduction of the CMS.****
>
> ** **
>
> Could you follow the information below to in regards to creating a
> thumbnail in a shared location and then have your users map to that file
> versus the svg? Then, when publishing, mod your XSL-FO to parse the file
> name to remove the extension if needed thus redirecting to the CMS copy.**
> **
>
> ** **
>
> *From:* Greg MacKenzie [
>
> "mygraphicspath\AIRSHIP-RevA.jpg"****
>
> ** **
>
> Then I'd probably change the entity reference and catalog with a simple
> text editor to point to the vector graphic prior to processing:****
>
> ** **
>
> > NDATA eps>****
>
> ** **
>
> PUBLIC "-// ABC-DEF::NAME //NONSGML AIRSHIP GRAPHIC//EN"****
>
> "mygraph...


















> is complete. This works out fairly well for new documents, but gets a bit
> cumbersome when managing subsequent editions (eg: remove and reinsert, or
> leave in, but instruct the authors to ignore the SVG markup)****
>
> ** **
>
> One approach we have used in the past is to put in reference tags that ou...

[bibach]

Can you configure your CMS to auto-generate a bitmap thumbnail whenever a
new version of an SVG graphic is checked in? If so, then having these
available in a central location would allow the authors to browse them and
insert them with a regular graphic tag, with all of the built-in support
Editor provides. The bitmap would probably be more efficient, as well.

Your build process could then just look for references to images in the
"thumbnail folder" and substitute the full SVG from the CMS.

-Brandon 🙂

[thendricks]

To add, in our environment we utilize the illustration software to generate a secondary file. What software are you using to generate the initial SVGs?

~Trevor

[berard]

So perhaps I'm going about this the wrong way, as everyone seems to imply
that the Editor has built-in support for inline graphic display (unless I'm
reading this wrong).

Again, conversion from SVG to JPEG, BMP etc is not an issue. We
technically get our SVGs direct from our illustrator (using Adobe
Illustrator, heh), but conversion to thumbnails in any form is trivial.
Also, the process of taking whatever format (custom tag, entityref, etc)
into the final SVG format during our content build is also a non-issue.

The problem I'm having is how to get the image to appear within Arbortext.
Let me attach a couple of screenshots to illustrate what I'm seeing, and
a rough mockup of what I'd like to see:
[image: Inline image 1]

This shows a sample entityref (called testgraphic) inline. What I would
like to see is a representation of the image (again, format can be anything
that works). e.g.:

[image: Inline image 2]

Typically, to manage this type of content insertion, we have a custom XUI
toolset that sits to the left of the Editor window. This allows for
selection of database objects, with the ability to "Insert at Cursor"

[image: Inline image 3]

This is an example of citation insert, where clicking "Insert at Cursor"
puts in tag content, in this case <citation db_id="12345"/">. We have
some FOSI rules that display correct numbering, and when moused over, we
display the citation text (sourced by its db_id) in the tool pane.

While I could probably do the same type of thing with a mouseover, it would
be nicer for graphics to have them displayed inline as mentioned in the
screenshot above.

The codebase currently manages checked out content locally (for offline
editing), but in this case, the image could reside on a server referenced
by a URI. The image could also be downloaded and cached locally if
necessary for Editor view.

Hopefully that's a bit more clear,
Keith

On Thu, Sep 20, 2012 at 5:42 PM, Hendricks Trevor <
-> wrote:

> To add, in our environment we utilize the illustration software to
> generate a secondary file. What software are you using to generate the
> initial SVGs?****
>
> ** **
>
> ~Trevor****
>
> ** **
>
> *From:* Brandon Ibach [
>
>
> -Brandon
> **
> ******
>
>

[ptc-953343]

I checked the help file to see how the SVG format is supported. It looks
like it can be treated as any other graphic format. From the original post
it sounded like you are including the SVG XML markup in the body of your
document XML. I beleive the approach you want to take is instead of
referencing a thumbnail, just reference a standalone SVG file. So the
Editor would display the content directly, but you might have to tweak
your publishing flow. So I'm thinking you would have something like
<graphic file="file.svg"/">.

Here is what I found on the SVG format in Editor

Displaying SVG graphics with the Batik SVG Toolkit

By default, SVG graphics are displayed in Arbortext Editor using the Batik
SVG Toolkit distributed by the Apache Software Foundation. A complete
description of the Batik SVG Toolkit and its SVG support can be found at
xmlgraphics.apache.org/batik/.

When publishing documents containing SVG images for print output using the
Batik SVG Toolkit, Arbortext Editor converts each SVG image to a TIFF
image with a resolution of 300 dpi. Change this resolution setting with
the defaultprintdpi option.

When publishing documents containing SVG images for screen display (HTML,
Web, Wireless, and so on), Arbortext Editor by default converts each SVG
image to a PNG image with its resolution set to the workstation's current
display resolution. Change this resolution setting with the
defaultscreendpi option. To specify that the SVG images are to pass
through the publishing process for screen display without being converted
to PNG images, add svg to the list of formats set with the
APTCOPYGRAPHICEXTS environment variable.

Displaying SVG graphics with Arbortext IsoView

If desired, you can display SVG graphics in an embedded Arbortext IsoView
control in the Arbortext Editor Edit view. To display SVG graphics in the
Arbortext IsoView control, you must enable SVG graphics support through
the isoviewfileformats option. Arbortext IsoView provides partial support
for the Scalable Vector Graphics (SVG) Tiny 1.2 Specification W3C
Candidate Recommendation. The following SVG Tiny 1.2 features are not
supported:
Filter elements
Gradients
Scripts
Style
Symbols
SVG fonts and some text constructs
SVG microDOM
animation features:
visibility
pointer-events
stroke
stroke-width
fill
font-size
transforms of objects

Note that Arbortext IsoView will display any compliant SVG file and will
ignore SVG features that IsoView does not support



> So perhaps I'm going about this the wrong way, as everyone seems to imply
> that the Editor has built-in support for inline graphic display (unless
> I'm
> reading this wrong).
>
> Again, conversion from SVG to JPEG, BMP etc is not an issue. We
> technically get our SVGs direct from our illustrator (using Adobe
> Illustrator, heh), but conversion to thumbnails in any form is trivial.
> Also, the process of taking whatever format (custom tag, entityref, etc)
> into the final SVG format during our content build is also a non-issue.
>
> The problem I'm having is how to get the image to appear within Arbortext.
> Let me attach a couple of screenshots to illustrate what I'm seeing,
> and
> a rough mockup of what I'd like to see:
> [image: Inline image 1]
>
> This shows a sample entityref (called testgraphic) inline. What I would
> like to see is a representation of the image (again, format can be
> anything
> that works). e.g.:
>
> [image: Inline image 2]
>
> Typically, to manage this type of content insertion, we have a custom XUI
> toolset that sits to the left of the Editor window. This allows for
> selection of database objects, with the ability to "Insert at Cursor"
>
> [image: Inline image 3]
>
> This is an example of citation insert, where clicking "Insert at Cursor"
> puts in tag content, in this case <citation db_id="12345"/">. We have
> some FOSI rules that display correct numbering, and when moused over, we
> display the citation text (sourced by its db_id) in the tool pane.
>
> While I could probably do the same type of thing with a mouseover, it
> would
> be nicer for graphics to have them displayed inline as mentioned in the
> screenshot above.
>
> The codebase currently manages checked out content locally (for offline
> editing), but in this case, the image could reside on a server referenced
> by a URI. The image could also be downloaded and cached locally if
> necessary for Editor view.
>
> Hopefully that's a bit more clear,
> Keith
>
> On Thu, Sep 20, 2012 at 5:42 PM, Hendricks Trevor <
> -> wrote:
>
>> To add, in our environment we utilize the illustration software to
>> generate a secondary file. What software are you using to generate the
>> initial SVGs?****
>>
>> ** **
>>
>> ~Trevor****
>>
>> ** **
>>
>> *From:* Brandon Ibach [
>>
>>
>> -Brandon
>> **
>> ******
>>
>> On Thu, Sep 20, 2012 at 3:05 PM, Keith Berard <->
>> wrote:***
>> *
>>
>> Thanks for all of the suggestions thus far. I should note that I'm not
>> really concerned about any type of conversion (whether it be to jpg, or
>> to
>> convert entities to SVG; that is a simple r...

















































>>
>> "mygraphicspath\AIRSHIP-RevA.jpg"****
>>
>> ****
>>
>> Then I’d probably change the entity reference and catalog with a simple
>> text editor to point to the vector graphic prior to processing:****
>>
>> ****
>>
>> >> NDATA eps>****
>>
>> ****
>>
>> PUBLIC "-// ABC-DEF::NAME //NONSGML AIRSHIP GRAPHIC//EN"**...





















>> copy
>> is complete. This works out fairly well for new documents, but gets a
>> bit
>> cumbersome when managing subsequent editions (eg: remove and reinsert,
>> or
>> leave in, but instruct the authors to ignore the SVG markup)****
>>
>> ****
>>
>> One approach we have used in the past is to put in refer...

[bibach]

Editor can display most types of graphics inline (with just a few
exceptions, like EPS images without an embedded preview bitmap).

The main requirement is that Editor needs to know that an element
represents a graphic reference. This can be configured in your doctype's
DCF file, with a "Graphic" element in the "Specials" element. The
"element" attribute specifies the name of the element and the "filename"
attribute specifies the name of the attribute that will contain the file
name of the graphic.

If the tag you're using to insert the graphic is configured properly and
the graphic doesn't show (or, more specifically, just shows a little icon
next to the tag), you may need to set the "graphicdisplay" option to "on".
This is also available in Tools->Preferences under the "View" category as
a "Graphics as Icons" checkbox, which you'll want clear for the graphic
itself to display. This option can be nice for authors who are willing to
forego (at least temporarily) seeing the graphics in exchange for better
performance, as a document with many or large graphics will be slower to
load, scroll, etc.

-Brandon 🙂

[berard]

Wow, I absolutely had no idea that was possible. So simple, and it even
supports URLs.

In my DCF I did the following:
<graphic element="testgraphic" filename="file"/">

In my DTD I did the following:

file CDATA #IMPLIED
db_id CDATA #IMPLIED
>

Then my XML can insert:
<testgraphic file="&lt;a" style="COLOR:" blue;=" text-decoration:=" underline&quot;=" target="_BLANK" href="http://10.37.1.209/SVG/Thumb/12345.gif"">http://10.37.1.209/SVG/Thumb/12345.gif" db_id="12345" />

I was _so_ hoping it would be this easy, and I can even use my standard
insert methods and add additional metadata (eg: db_id) with a dynamic URL
for the image.

Thanks again, this will work out beautifully.

Keith Berard
Milliman Care Guidelines


On Fri, Sep 21, 2012 at 10:39 AM, Brandon Ibach <
brandon.ibach@single-sourcing.com> wrote:

> Editor can display most types of graphics inline (with just a few
> exceptions, like EPS images without an embedded preview bitmap).
>
> The main requirement is that Editor needs to know that an element
> represents a graphic reference. This can be configured in your doctype's
> DCF file, with a "Graphic" element in the "Specials" element. The
> "element" attribute specifies the name of the element and the "filename"
> attribute specifies the name of the attribute that will contain the file
> name of the graphic.
>
> If the tag you're using to insert the graphic is configured properly and
> the graphic doesn't show (or, more specifically, just shows a little icon
> next to the tag), you may need to set the "graphicdisplay" option to "on".
> This is also available in Tools->Preferences under the "View" category as
> a "Graphics as Icons" checkbox, which you'll want clear for the graphic
> itself to display. This option can be nice for authors who are willing to
> forego (at least temporarily) seeing the graphics in exchange for better
> performance, as a document with many or large graphics will be slower to
> load, scroll, etc.
>
> -Brandon 🙂
>
>
>
>