RE: Guidance for creating SLRÂprofile

Hi Fredrik,

thanks a lot for the quick and extensive response. You are right, Iâm definitely aiming for a proprietary usage.

Based on your feedback Iâve came up with something like this (havenât chosen the prefix/name yet):

<slr:profiles generalProfile="my-org:foo-ui">

<my-org:text-align>center</my-org:text-align>

<my-org:font-family>A Font Face</my-org:font-family>

<my-org:font-size>13px</my-org:font-size>

<my-org:font-color>#ffffff</my-org:font-color>

<my-org:font-weight>normal</my-org:font-weight>

<my-org:font-style>normal</my-org:font-style>

</slr:profiles>

<slr:data profile="">

<my-org:profile xml:id="slr1">

<my-org:font-size>8px</my-org:font-size>

<my-org:top>11px</my-org:top>

<my-org:left>7px</my-org:left>

<my-org:width>47px</my-org:width>

<my-org:height>19px</my-org:height>

</my-org:profile>

</slr:data>

<source><sc canDelete="no" canOverlap="no" id="1" slr:sizeInfoRef="slr1" />Button<ec

canDelete="no" canOverlap="no" startRef="1" /></source>

</segment>

</unit>

Iâve put defaultâs in the <slr:profiles>, though Iâm overwriting <my-org:font-size> later. At the moment, Iâm considering just single level restrictions, though I could put slr:sizeInfoRef on the whole unit/group as needed (with appropriately placed <slr:data>).

Coordinates/dimensions and overrides are stored in one of <slr:data>/<my-org:profile> children, referenced from <sc>/<ec> via slr:sizeInfoRef. Iâve opted for codes, as they can be protected using Editing Hints (did not want to bother with markers that can be removed in target). Iâm using xml:id for identifying the <slr:data> child. Still not sure about canOverlap though.

Using slr:sizeInfoRef due to size of the data and my overall preference.

What do you think?

Regards,

JÃn

From: Estreen, Fredrik [mailto:Fredrik.Estreen@lionbridge.com]
Sent: Thursday, July 12, 2018 00:12
To: Jan Husarcik <JHusarcik@moravia.com>; xliff-users@lists.oasis-open.org
Subject: Re: Guidance for creating SLR profile
Sensitivity: Private

Hi Jan,

I'm not active with XLIFF standardization at this time but I try to keep an eye on it and worked a lot on this module in the past. So I'll try to provide some guidance. First something you probably already know, the type of profile you want to design would be very hard to design for general use, but could more easily be designed for proprietary or case specific usage.

You will want to design a "general" profile for this use case, the module supports both a general size profile and a storage size profile in parallel.

Step one is to pick a prefix that could make sense for a collection of custom profiles for a case or your organization. And a name for the actual profile. Like "my-org:foo-ui"

Depending on how configurable you want the profile to be you may or may not need to define a way to express the base parameters in the slr modules <profiles> element using elements from a namespace outside XLIFF, likely one defined by you. For rendering things like DPI, layout engine and engine options, default font parameters etc could make sense. You will want to place any parameters that apply to the file/group/unit level and affect the overall profile behavior here.

Next you will want to define how to express the size restriction on some portion of content. If you have a single line it could be as simple as just the number of pixels. It sounds like you may want a box and then for a 100x50 box something like "100x50" or "100 50" would be a straight forward notation. If you plan to support different units in the future "100px 50px" or similar would make more sense. You would use values of the form you define here in the "sizeRestriction" attribute from the slr module to restrict the size of a portion of content. It is supported on files, groups, units, marker (mrk/sm+em) spans and spanning inline codes (pc/sc+ec). So you have the expressiveness it sounds like you need by using this attribute. When restricting the size of multiple spans in a single unit you will need to do that using marker or inline codes. Unless you already have inline codes that fully contain your spans I would recommend using the inline marker elements. Both ways are independent of segmentation. Don't try to tie restrictions to segments as that would break the expectations that tools can re-segment units. You should probably make a decision if you want to be able to support hierarchical or just single level restrictions. Like a max combined size for a box/frame/dialog and inside it individual constraints on spans of content. If you think about it from the beginning you can likely start out with single level and have a path to do more complex later.

Finally you will want to define how you express changes that affect rendering like a change in font, font-size, font-weight, etc. This can be done in two ways either fully inline using the "sizeInfo" attribute or as referenced information using the "sizeInfoRef" attribute which would point to a <data> element in the same <unit> or an ancestor <group> or <file> element. Which method to use mostly depends on how big the information is and what style you prefer. You can even mix the two but I would personally stick to one or the other. This information can be placed on files/groups/units and all the inline original code elements (pc,sc,ec,ph). This decouples the effect of the native markup from the original markup itself. Which is useful if you want to be able to use the same core checker on different types of markup or if the markup changes. These attributes can also be used to express a fixed or maximum size of the element the attribute is present on. Like a <ph> that will be replaced by a variable of up to N characters or an icon that is XxY pixels big.

Hope this helps a bit and I'm happy to try answering other questions in this area.

Best regards,

Fredrik Estreen

From: Jan Husarcik <JHusarcik@moravia.com>
Sent: Wednesday, July 11, 2018 11:00:54 PM
To: xliff-users@lists.oasis-open.org
Subject: [xliff-users] Guidance for creating SLR profile

Hi,

Iâm looking for a guidance for creating a SLR profile with following purpose:

Validate that target text with defined

- font face

- font size (px)

- decorations (bold, italic, small-caps, â)

would fit into text box of defined dimensions (px). Itâs likely that there would be multiple spans with different limitations within single <unit>.

Would you kindly advise?

Topicâs briefly mentioned in 2.1 spec (5.7.7 Third party profilesâ http://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html#d0e16864), but without further details.

Regards,

Jan

xliff-users message