Support for shearing of lines and inline elements

palemieux commented 6 years ago

Japanese subtitles commonly use shearing of text, as illustrated below.

Not sheared:

plain

Sheared:

shear

Couple of observations:

while shearing might not be appropriate for books, it is commonly used for subtitles
shearing is not applied to individual characters, but instead to complete blocks -- each of the digits in 1998 is not sheared individually, and both ruby text and base are sheared as a single block
the shear angle is author-specified
it should be possible to shear individual lines as well as groups of lines

CSS Transforms Module Level 1 skewX() and skewY() can be applied to blocks but neither to lines nor inline elements

See tts:shear, tts:lineShear and tts:fontShear at TTML2.

astearns commented 6 years ago

I believe we've been intending to support this with font-style: -20% (or whatever value gives you the synthesized oblique you require)

https://drafts.csswg.org/css-fonts-4/#font-style-prop

palemieux commented 6 years ago

@astearns I read font-style: -20% as applying to each character individually. Per the illustrations above, the shear is applied to ruby base and text as a block.

astearns commented 6 years ago

We might be able to handle that by defining the desired outcome for upright characters, text-combine-upright runs and ruby text when synthesized oblique is applied.

kojiishi commented 6 years ago

Can I ask where you got the screenshot? I wonder how much common to shear ruby text together. AFAIK, it is not common in publishing world. Maybe different in TTML usages?

palemieux commented 6 years ago

AFAIK, it is not common in publishing world. Maybe different in TTML usages?

Yes, as I understand it, shearing is not common in printing/publishing, but common in subtitles.

Below is a selection of pointers:

thread at https://github.com/w3c/ttml2/issues/784
SMPTE ST 428-7, which is the subtitling format used worldwide for cinema
SST G1 manual

Can I ask where you got the screenshot?

The screen shot was generated by imscJS, which an implementation of IMSC 1.1. See the sample app and the following IMSC 1.1 sample.

<?xml version="1.0" encoding="UTF-8"?>
<tt xmlns:tt="http://www.w3.org/ns/ttml"
    xmlns:ttp="http://www.w3.org/ns/ttml#parameter"
    xmlns="http://www.w3.org/ns/ttml"
    xmlns:tts="http://www.w3.org/ns/ttml#styling"
    ttp:contentProfiles="http://www.w3.org/ns/ttml/profile/imsc1.1/text">
  <head>

    <styling>

      <style xml:id="s1" tts:showBackground="whenActive" tts:color="white" tts:writingMode="tbrl" tts:fontSize="150%"/>

    </styling>

    <layout>

      <region style="s1" xml:id="vertical" tts:origin="55% 5%" tts:extent="40% 90%"/>

    </layout>

  </head>

  <body>

    <div begin="0s" end="1s" tts:shear="16.67%" region="vertical">

      <p>
        <span tts:ruby="container" tts:rubyAlign="spaceAround" tts:rubyPosition="before">
          <span tts:ruby="baseContainer"><span tts:ruby="base">山</span></span><span tts:ruby="textContainer"><span tts:ruby="text">やま</span></span></span>の
      </p>
      <p>
        <span tts:ruby="container" tts:rubyAlign="spaceAround" tts:rubyPosition="after">
         <span tts:ruby="baseContainer"><span tts:ruby="base">最多<span tts:textCombine="all">1998</span>年</span></span>
          <span tts:ruby="textContainer"><span tts:ruby="text">ルビサンプル</span></span>
        </span>
      </p>

    </div>

  </body>

</tt>

kojiishi commented 6 years ago

Yes, as I understand it, shearing is not common in printing/publishing, but common in subtitles.

Sorry, it looks like I mislead you.

Shearing is common in printing/publishing. We've been discussing how to do this in css-fonts for years.

When it has ruby, it is common to shear ruby base and ruby text separately in printing/publishing, and that's the only portion where we see TTML has different requirement from printing/publishing.

So the question is, is shifting ruby text position an important factor to need a separate mode for TTML? Do you have any pointers that indicates ruby positioning of sheared text should be different from printing/publishing?

kojiishi commented 6 years ago

For text-combine-upright, it's a good point. The requirement is same, we should fix it in css-fonts.

palemieux commented 6 years ago

So the question is, is shifting ruby text position an important factor to need a separate mode for TTML? Do you have any pointers that indicates ruby positioning of sheared text should be different from printing/publishing?

See w3c/ttml2#784 for some pointers.

@akiseino who has direct experience with cinema subtitling should be able to provide additional evidence.

kojiishi commented 6 years ago

I see @akiseino says on 23 May:

The ruby by individual, is moved to left side. But it's center by block.

It indicates ruby should be centered, not to be moved by shearing. IIUC this is the same as printing/publishing.

palemieux commented 6 years ago

It indicates ruby should be centered, not to be moved by shearing. IIUC this is the same as printing/publishing.

Can you provide an illustration to avoid any misunderstanding?

svgeesus commented 5 years ago

litherum commented 5 years ago

css-meeting-bot commented 5 years ago

The CSS Working Group just discussed Shearing Vertical Text.

The full IRC log of that discussion

<fantasai> Topic: Shearing Vertical Text
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2983
<birtles> pal: today there's the ability to specify slant on individual characters using oblique
<birtles> ... or italic
<birtles> ... sometimes it's useful to apply shear not on character-by-character but entire line
<birtles> ... that's desirable to apply alignment between ruby and base text
<birtles> ... it's subtle but really matters to folks that care
<birtles> ... separate issue about whether or not we should be able to specify the angle of shear per-character
<birtles> ... issue here is applying by the whole line
<birtles> nmccully: in print, it's not keeping the height/width of the line when you shear it
<birtles> ... you change the shape of the box of each character to a diamond
<birtles> ... it's call shatai in Japanese
<myles> https://helpx.adobe.com/ch_fr/indesign/using/formatting-cjk-characters.html
<myles> this is what Nat is talking about
<birtles> ... in subtitles has it become just a shear?
<birtles> pal: it seems to be just a one-dimensional thing in subtitles
<birtles> ... not sure if it's an artistic desire or technical limitation
<birtles> koji: the difference here is a position of the ruby, right?
<birtles> pal: yes
<birtles> koji: I'm not sure about this use case, but for me changing the position of the ruby looks to me
<birtles> ... shearing the individual characters looks better to me
<birtles> pal: on the thread some others seem to prefer shearing the whole line
<birtles> fantasai: for print we know they want the per-character approach
<birtles> ... so I suggest we propose that and take that to the subtitle group and see if that is acceptable
<birtles> ... it's possible that the request here for shearing the whole inline-block is just coming from technical limitations
<birtles> pal: I like the idea of going back and asking questions
<birtles> ... but the issue opened against ttml was specifically about not being able to shear the whole block
<birtles> fantasai: I thought the problem was that italics shears in the wrong direction
<birtles> koji: can you point to specific individual / issue so I can follow up
<florian> q+
<birtles> koji: I can't see any ruby in that issue
<Rossen__> https://w3c.github.io/ttml2/index.html#style-attribute-shear
<AmeliaBR> text-combine-upright does look bad with individual character shear: https://github.com/w3c/ttml2/issues/784#issuecomment-390856934
<fantasai> https://github.com/w3c/ttml2/issues/784
<birtles> florian: you said we want to shear the entire line OR paragraph
<birtles> ... these are two things
<birtles> ... for the second option, CSS transforms will do it
<birtles> pal: ttml can do all three: character, line, paragraph
<birtles> florian: the difference with ruby is more subtle
<birtles> ... but the text combine upright case is more obviously different
<birtles> pal: the issue in 2983 shows a good example
<birtles> ... 2983 ends with a question I asked
<birtles> myles: any proposal for how the author would describe to the browser the effect they desire
<birtles> pal: yes there is a proposal there
<birtles> myles: so a new property?
<birtles> ... has anyone considered re-purposing the new syntax for font-style to describe the shearing?
<birtles> glenn: no I have not
<birtles> ... we introduced three new properties: shear (block), line-shear (per-line including tatechuuyoko), font-shear (glyph box by glyph box)
<birtles> myles: one option would be to have font-style: oblique -14deg does shear
<birtles> ... and if it looks bad it's a browser bug
<birtles> fantasai: I don't think it will look good if there is latin text involved
<birtles> myles: there's an issue in the agenda for that later today
<birtles> fantasai: I don't think we can mix this with the oblique/italic feature
<birtles> nmccully: It's complicated to have these different properties, but I agree with fantasai's desire to have a separate feature for this
<birtles> ... to say I want to shear these things correctly, and provide an angle, and let the UA decide how to do it (especially for mixed text)
<birtles> koji: I agree with myles and don't understand why specifying an angle doesn't work
<birtles> ???: because the fonts
<birtles> koji: what exactly doesn't work?
<birtles> myles: my proposal is that the font-style property does more than just font selection
<birtles> ... it does font selection as it does today and also does the transform as necessary
<birtles> pal: the way this was explained to me is that the desired effect was literally just shearing
<birtles> koji: we understand, but the point is there are other glyph shearing use cases
<birtles> ... that is what myles is proposing
<birtles> pal: we need to understand three distinct use cases: per block, per line, per character
<nigel> s/???: because the fonts/nigel: you're asking a lot of the implementation and reducing authoring flexibility
<birtles> koji: we have per block already, myles is proposing per-character
<birtles> ... we are wondering what is needed for line shearing
<birtles> fantasai: this example on the screen shows why we can't cover the line case with the same per-glyph approach
<birtles> ... the characters all shear in different directions when using font-style: oblique
<birtles> (example includes mixed CJK and vertical and horizontal latin)
<birtles> myles: yes, we want to discuss this later today
<AmeliaBR> +1 for keeping this logically separate; too confusing when mixing latin and upright scripts
<birtles> nigel: I think we've understood the use case better, any proposal action?
<birtles> fantasai: CSS definitely needs to solve the per-character shearing
<birtles> ... block shearing is solved
<birtles> ... open question about if more is needed for line-shearing
<birtles> pal: for block shearing, transform shears the background too. Is that ok?
<birtles> AmeliaBR: you need a wrapper element if you want to avoid that
<birtles> pal: does the size change too for the block too?
<birtles> ... it doesn't so it extends beyond the background
<birtles> ... any chance of a shear property that affects block size?
<birtles> myles: transforms that affect layout?
<birtles> pal: yes
<birtles> AmeliaBR: it could be a dedicated block shear property
<birtles> florian: the general solution for transforms that affect layout is hard
<birtles> ... a limited use case could be ok
<birtles> pal: just reacting to the idea that block shearing is solved

cconcolato commented 4 years ago

What should be done to progress the support for line-shearing in CSS?

BHolterMedia commented 1 month ago

Hi all just adding my $.02 since I just discovered this issue and how it impacts shearing of Japanese subtitles in CSS scenarios. This impacts all Japanese subtitles we author and while many of the use cases do not depend on CSS, many do and require workarounds to accomplish on screen what has been authored in the ttml itself. For my use case specifically the region extents cropping text when shearing is applied, requiring modification to the style settings that we otherwise wouldn't want to include. See below for an example of shearing being cropped as displayed via imscJS CSS.

For more media context, more and more content owners and media platforms are implementing IMSC as their core timed text format for media inventories and mezzanine time text distribution assets, but many platforms still perform format conversions (converting from IMSC to VTT, etc.) to display subtitles due to limitations like this (and of course for other reasons internal to their own media processing pipelines).

w3c / csswg-drafts

Support for shearing of lines and inline elements #2983