- From: Andreas Tai <tai@irt.de>
- Date: Tue, 16 Jul 2013 17:24:09 +0200
- To: Glenn Adams <glenn@skynav.com>
- CC: public-tt <public-tt@w3.org>, John Birch <John.Birch@screensystems.tv>, nigel.megitt@bbc.co.uk, Pierre-Anthony Lemieux <pal@sandflow.com>
- Message-ID: <51E56599.1000603@irt.de>
Thanks for the very helpful answers, Glenn! Am 16.07.2013 16:24, schrieb Glenn Adams: > > > On Tue, Jul 16, 2013 at 7:09 AM, Andreas Tai <tai@irt.de > <mailto:tai@irt.de>> wrote: > > Dear all, > > We had an extensive discussion on the EBU mailing list regarding > the relationship between cell resolution, font-size and > line-height. At some point we found out that the TTML mailing list > is possibly the better place to discuss some of the question that > came up. > > For completeness I include part of the mailing list thread below. > > Some questions are highlighted below: > > ---------------------------- > Font-Size > ---------------------------- > In TTML scaling is applied to the glyph's EM square. As Nigel > noted below "the font has an EM square and each glyph has its own > width and height that may be different from the EM square". So > possibly there is clarification needed. > > As I understand the rendering processor would choose a font that > best matches the specified font characteristics (including the > font-size) and then scale the font/the EM square to the computed > font-size. Is this correct? > > > Yes. > > So, assumed there is no ancestor element with a specified > font-size, the root container height is 720px, the grid is "32 15" > and you choose a font-size of 100% then the computed font-size > would be 720px/15 = 48px? > > > Yes. Since the initial font size, as applied to the outermost element > (of the intermediate synchronic document instance) of the style > inheritance process [1], namely tt, is 1c, and since, given a 720px > height(RC), then the computed cell height is as you say: 48px. > Therefore, 100% or 48px is 48px. > > [1] > http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#semantics-style-inheritance > > > Another question is how this will be mapped into CSS. Assumed the > font-family is specified as Arial, should the calculated value of > the CSS property font-size be 48px? Would the scaling in current > browser implementation work as intended by the TTML definition and > scale the EM square of the chosen Arial font? > > > If we define TTML pixels to be equivalent to CSS pixels, then yes, or > at least, yes, I expect that will be the mapping we define. However, > we haven't yet defined TTML pixels, so we'll have to progress the > mapping definition before we have a definitive answer. Even if we > choose a different definition of pixels (and it is unlikely we would > do so), then TTML pixels could be further scaled as required to map to > CSS pixels. > > > > ---------------------------- > Line height > ---------------------------- > Obviously the relationship between font-size and line-height is > very important for subtitling. In legacy formats subtitles are > positioned on an exact number of lines. To control the grid of > lines in TTML the line-height has to be specified explicitly. But > as the font-size would not shrink or increase automatically > according to a fixed line-height this has to be done with care > (e.g. to avoid colliding glyphs). > > If you give up the control over the rendered line height you could > choose the initial value of "normal". The computed value for the > line-height would be the same as the largest font size that > applies to any descendant element[1]. So if the font-size is 48px, > the value of line-height will be 48px as well. > > This could actually result in unwanted presentation because as I > understood there will be no white space between the content of two > adjacent line (so there will be no leading?). > > In XSL:FO 1.1 (same as XSL 1.1) the value of “normal” for > line-height is defined as follows [2]: > > > 7.16.4 "line-height" > > [Normal] tells user agents to set the computed value to a > "reasonable" value based on the font size of the element. [...] We > recommend a computed value for "normal" between 1.0 to 1.2. > > The same definition can be found in the CCS 2 spec. > > This user agent dependent behaviour is reflected in current > browser implementations. The author cannot assume a specific > line-height when setting the value to “normal” even if he knows > font-family and font-size. > So they may be a problem when mapping TTML lineHeight with the > value of “normal” to the CSS property line-height and the value > “normal”?! > > > Since TTML uses a more specific definition of line height [2]: > > If the value of this attribute is |normal|, then the initial value of > the style property must be considered to be the same as the largest > font size that applies to any descendant element. > > It would be incorrect to map the value normal to the CSS value normal > (unless we revise the TTML definition to use the vague definition of CSS). > > [2] > http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#style-attribute-lineHeight > > I see also that we need to slightly clarify the TTML definition to read: > > If the value of this attribute is |normal|, then the initial value of > the style property must be considered to be the same as the largest > font size that applies to any descendant element in the intermediate > synchronic document instance. > > The need for this clarification should be obvious, since a descendant > in the original document may not be in a given intermediate document > (e.g., because it was selected into a different region). > > > ------------------------------- > Font-Size / Line Height > ------------------------------- > Currently the cell resolution is the only way to relate the > font-size to the height of the video (if the root container is set > by a specification explicitly to the size of the video). > > > Correct. > > As Sean stated the “vh “ strategy for font-size is currently > evaluated to relate the font-size directly to the size of the > video. I assume that this should be similar (or same) to what is > proposed for viewport-relative-lengths in CSS3 [4] and defined as > well in CSS files of "Conversion of 608/708 captions to WebVTT" > [5]. Possibly it can be discussed on the list how this can be > applied to TTML and if this would be solution for the Issue-225. > > > I expect we will introduce vh/vw units into TTML.next, and, mutatis > mutandis, use the definitions you cite from [4]. > > > Best regards, > > Andreas > > [1] > https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml10/spec/ttaf1-dfxp.html?content-type=text/html%3bcharset=utf-8#style-attribute-lineHeight > [2] http://www.w3.org/TR/xsl/#line-height > [3] http://www.w3.org/TR/CSS2/visudet.html#propdef-line-height > [4] http://www.w3.org/TR/css3-values/#viewport-relative-lengths > [5] > https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html#browsers > [6] http://www.w3.org/AudioVideo/TT/tracker/issues/225 > > > -------- Original-Nachricht -------- > Betreff: Re: [EBU-TT-D] Updated list of proposed TTML features > Datum: Mon, 8 Jul 2013 09:14:19 +0000 > Von: Nigel Megitt <nigel.megitt@bbc.co.uk> > <mailto:nigel.megitt@bbc.co.uk> > An: John Birch <John.Birch@screensystems.tv> > <mailto:John.Birch@screensystems.tv>, Andreas Tai <tai@irt.de> > <mailto:tai@irt.de>, "EBU-TT-D@list.ebu.ch" > <mailto:EBU-TT-D@list.ebu.ch> <EBU-TT-D@list.ebu.ch> > <mailto:EBU-TT-D@list.ebu.ch> > > > > I agree the concepts of the line spacing and font height need to be > separately and clearly defined to allow implementations to be able to > render text as it's intended and to avoid the confusion you've described > John. I think this is what the TTML spec is trying to do by allowing > lineHeight and fontSize to be specified with a clear relationship. However > it falls short as you've pointed out. I'd propose the following remedial > steps, certainly in EBU-TT and hopefully in a future iteration of TTML: > > 1. State that we (TTML) assume that any presentation device will apply > appropriate rules to generate a font of the required size, regardless of > what algorithm is used either to scale or select a pre-defined font of a > similar size. > > The problem with the current TTML wording is that it says (in > http://www.w3.org/TR/ttaf1-dfxp/#style-attribute-fontSize) both "font size > is interpreted as a scaling transform to the font's design EM square" and > "horizontal and vertical scaling of a glyph's em square" which seem to > conflict. Is it each individual glyph that should be scaled, or the entire > font? As I understand it the font has an em square and each glyph has it's > own width and height that may be different from the em square. > > 2. State that TTML assumes that the em square unit is a suitable line > spacing size for the chosen font, i.e. that it includes the ascent, > descent and extra space needed above and below, left and right. The > articlehttp://www.microsoft.com/typography/otspec/TTCH01.htm includes a > good picture of this in the section headed "FUnits and the em square". > > I think both of these could be inferred from the current spec but by > making them explicit it would help to avoid the confusion. > > The result should be that each row in a cell grid is 1c and there's no > need for 80%s and 120%s here and there (unless a particular visual effect > squeezing or stretching the baseline spacing is desired!). > > Kind regards, > > Nigel > > > > -------- Original-Nachricht -------- > Betreff: Re: [EBU-TT-D] Updated list of proposed TTML features > Datum: Wed, 3 Jul 2013 18:13:19 +0200 > Von: Andreas Tai <tai@irt.de> <mailto:tai@irt.de> > An: John Birch <John.Birch@screensystems.tv> > <mailto:John.Birch@screensystems.tv> > Kopie (CC): EBU-TT-D@list.ebu.ch <mailto:EBU-TT-D@list.ebu.ch> > <EBU-TT-D@list.ebu.ch> <mailto:EBU-TT-D@list.ebu.ch> > > > > Thanks for the comments, John. In general I think that we won´t > constrain the supported TTML feature list for EBU-TT-D. This is > more about a best practice recommendation. > > See further comments in-line. > > Best regards, > > Andreas > > >> *From:*Andreas Tai [mailto:tai@irt.de] >> *Sent:* 02 July 2013 15:10 >> *To:* John Birch >> *Cc:* Nigel Megitt; EBU-TT-D@list.ebu.ch >> <mailto:EBU-TT-D@list.ebu.ch> >> *Subject:* Re: [EBU-TT-D] Updated list of proposed TTML features >> >> Hi John, >> >> I see some problem if both, font-size and line-height, are >> specified explicitly . Given the uncertainties (e.g. the chosen >> font) from my view there is a high probability of unwanted >> presentation. Worst case would be that the lines overlap because >> of a font that is not appropriate for the line-height. >> >> >> I see the opposite. By specifying both line height and font size >> you are defining exactly the desired outcome. There is NO >> interpretation possible. If the font size is less than the line >> height then the EM cell must be smaller than the line height. If >> a ‘badly designed font’ where the glyph exceeds the em square by >> a large amount is specified, then that problem exists regardless >> of whether you are explicit about line height or choose a value >> of ‘normal’. Fonts that exceed the em square are unlikely to be >> used in subtitling, as (at least in my experience) they are >> usually those that represent cursive styles. >> >> > > I am not sure if you would have problems in current CSS browser > implementations even if you have a "badly designed font". I would > still expect that the displayed font will not exceed the line. > > >> To set the line-height to "normal" is a common solution in CSS >> and the default value in CSS as in TTML. I therefore think that >> this concept would be understood by the web community. Of course >> it will be far better, if you had a reverse dependency: you set a >> fixed line-height and the rendering machine has to choose the >> appropriate font/font-size to fit in this line. But I do not >> expect that this will be chosen solution in future editions of >> TTML or CSS. >> >> >> The problem is that CSS does not typically use a concept of >> directly controlling line positions… the use of ‘normal’ >> effectively leaves the line height up to the renderer, based on >> the font size and text content. This is absolutely contrary to >> what is required for subtitling, where the extent of the text >> MUST be controlled. >> > I would not take this for granted. The input I get from our > broadcasters is that exact line-height and exact positions are no > hard requirements, while colours are of high importance. > >> The fact that this effect is ‘understood by the community’ in >> itself creates a problem. The community needs to re-understand >> that, in the context of subtitling, controlling the exact text >> size and position is more important. >> > > I am sceptical about "educating" the web community. In the past > (and in the present) this was not very successful. What I get from > our discussions is that a good integration in HTML and CSS is > important for EBU-TT-D. I don´t think that these standards and > implementations will worry to much about specific subtitling and > captioning requirements. > > I agree exactly, that shrinking to fit a line (or maybe a region) > would be far better, but this again is an unknown concept within > CSS. In fact I am not sure I would like this any better, since the > likelihood is that you would then get subtitles of varying text > sizes throughout a presentation. However, I’m pretty sure most > implementations will support line height values other than ‘normal’. > > As said above: I think both strategies (line-height = normal or > choose exact line-height) will be allowed in EBU-TT-D. > > >> I agree, that we should not change mapping of the root container >> to the size of the video. I think that this interpretation has >> become accepted. From an interoperability perspective this is of >> high value : ) >> >> Yes, absolutely. >> >> >> Best regards, >> >> Andreas >> >> Am 02.07.2013 14:16, schrieb John Birch: >> >> Hi Andreas, >> >> Yes, these are important considerations… For me, both the >> line height and the font-size would be specified as >> percentages (the line height would be slightly larger than >> the font-size). >> >> E.g. line height 7%, font size 6%. This would mean 12 rows of >> characters would occupy 84% of the root container. Roughly >> equivalent to a Teletext presentation. A 6% / 7% font to line >> ratio is approx. 116%. >> >> Personally I find the alternative approach to be more >> difficult to comprehend. Particularly when you factor in the >> ‘safe area’ concept. >> >> If the cell resolution could be applied to a ‘super region’ >> (i.e. one that could be defined as the safe area) then it >> might be more straight forward. In other words conceptually >> the root container is not the full extent of the active >> video… but I don’t really want to go there – you then have >> problems when you want (and need) to write outside of the >> safe area (e.g. speech marks). >> >> Best regards, >> >> John >> >> *John Birch | Strategic Partnerships Manager | Screen >> *Main Line : +44 1473 831700 <tel:%2B44%201473%20831700> | >> Ext : 270 | Direct Dial : +44 1473 834532 >> Mobile : +44 7919 558380 <tel:%2B44%207919%20558380> | Fax : >> +44 1473 830078 <tel:%2B44%201473%20830078> >> John.Birch@screensystems.tv >> <mailto:John.Birch@screensystems.tv> | www.screensystems.tv >> <http://www.screensystems.tv> | >> https://twitter.com/screensystems >> <https://twitter.com/screensystems> >> >> *Visit us at >> SMPTE conference & exhibition, Stand G35, Sydney Exhibition >> Centre, Darling Harbour, 23-26th July* >> >> *P**Before printing, think about the environment* >> >> *From:*Andreas Tai [mailto:tai@irt.de] >> *Sent:* 02 July 2013 12:32 >> *To:* John Birch >> *Cc:* Nigel Megitt; EBU-TT-D@list.ebu.ch >> <mailto:EBU-TT-D@list.ebu.ch> >> *Subject:* Re: [EBU-TT-D] Updated list of proposed TTML features >> >> I don´t want to let go cell resolution for EBU-TT-D so >> easily ; ) I think there is value in this concept regardless >> of the legacy argument. For font-size it gives you a tool to >> design a grid of lines and decide how many lines you "intent" >> to address. After that you can choose the appropriate >> font-size in relation to this grid. >> >> The height of the font-size matches not exactly 1c. The rows >> should define the height of the line in the intended grid, >> not the height of the font. >> >> An important use case will be to translate the values for >> line-height and font-size to CSS. As in TTML the relationship >> between font-size and line-height can be expressed in CSS >> through the value "normal" for line-height. Then a line >> height that fits the font-size will be set through the >> renderer (the browser in the case of CSS). The recommended >> line-height in the CSS spec is 110 to 130% of the font-size. >> After some Browser tests I found that a font-size of 0.8c or >> 80% would be a good choice so that the grid will be filled >> but not extend the root container. >> >> This approach has some in computable variables (not only the >> concrete font that is used for presentation but as well for >> HTML/CSS the browser behaviour). Nevertheless I think this >> can be a good and transparent guide to select a font-size >> that is independent from the size of the video and preservers >> the concept of "lines". >> >> Best regards, >> >> Andreas >> >> >> Am 02.07.2013 12:16, schrieb John Birch: >> >> I have no problem at all with retaining cell resolution >> and grid based philosophies in Part 1 files… i.e. in >> archived exchanged subtitle files. >> >> Where I think the cell resolution grid strategy falls >> down is in the delivered distribution format, where >> arguably having a single way of expressing the >> presentation, in as simple a way as possible, is desirable. >> >> In my world there would (almost always) be a computer >> based conversion *from Part 1 to EBU-TT-D*. This >> conversion is not (necessarily) reversible. >> >> So, for example, we can translate from ‘cell resolution / >> grid’ into ‘percentage of root container’ when we move >> from a (part 2 style) Part 1 document to an EBU-TT-D >> document. >> >> A conversion away from mono spaced fonts might also be >> performed here too. Loss of some metadata is expected. >> Addition of some metadata (e.g. language track >> identification) might be necessary since although in the >> Part 1 world we talk about an external asset management >> system, that may not exist in the distribution context. >> >> Best, >> >> John >> >> *John Birch | Strategic Partnerships Manager | Screen >> *Main Line : +44 1473 831700 <tel:%2B44%201473%20831700> >> | Ext : 270 | Direct Dial : +44 1473 834532 >> <tel:%2B44%201473%20834532> >> Mobile : +44 7919 558380 <tel:%2B44%207919%20558380> | >> Fax : +44 1473 830078 <tel:%2B44%201473%20830078> >> John.Birch@screensystems.tv >> <mailto:John.Birch@screensystems.tv> | >> www.screensystems.tv <http://www.screensystems.tv> | >> https://twitter.com/screensystems >> <https://twitter.com/screensystems> >> >> *Visit us at >> SMPTE conference & exhibition, Stand G35, Sydney >> Exhibition Centre, Darling Harbour, 23-26th July* >> >> *P**Before printing, think about the environment* >> >> *From:*Nigel Megitt [mailto:nigel.megitt@bbc.co.uk] >> *Sent:* 02 July 2013 10:56 >> *To:* John Birch; Andreas Tai >> *Cc:* EBU-TT-D@list.ebu.ch <mailto:EBU-TT-D@list.ebu.ch> >> *Subject:* Re: [EBU-TT-D] Updated list of proposed TTML >> features >> >> Hi John, >> >> Thanks for the welcome back! >> >> On the authoring for legacy argument I don't particularly >> /like/ it either but I think we have to recognise it as a >> stage that a lot of adopters will feel they have to go >> through. If it looks as though they're blocked at that >> stage they may never get any further. And if they're >> doing that then they need to ensure that if the subtitles >> will be presented using a mono-spaced font there is >> enough space to fit the text on each row. Happily TTML >> supports mono-spaced fonts and there's been no suggestion >> so far that we should remove this support. >> >> Kind regards, >> >> Nigel >> >> *--* >> >> *Nigel Megitt* >> >> Lead Technologist, BBC Technology, Distribution & Archives >> >> Telephone: +44 (0)208 0082360 >> <tel:%2B44%20%280%29208%200082360> >> >> BC4 A3 Broadcast Centre, Media Village, 201 Wood Lane, >> London W12 7TP >> >> On 02/07/2013 10:25, "John Birch" >> <John.Birch@screensystems.tv >> <mailto:John.Birch@screensystems.tv>> wrote: >> >> Hi Nigel, >> >> Welcome back J >> >> Yep, definitely an elephant… and I agree that we >> should very much move away from grid based >> mentalities. In fact I don’t really have much >> ‘sympathy’ with the authoring for legacy argument, >> since realistically the required constraints are in >> the number of characters a line and the number of >> rows per screen. I don’t think there is a strong >> requirement for retaining a mono-spaced font concept. >> >> In terms of multiples, 160 by 360 also works, (with a >> rather strange higher resolution in the vertical >> dimension), giving a 4 by 9 cell for 40 x 24, and a 5 >> by 15 cell for 32 by 15. >> >> Personally though,*for EBU-TT-D*, I actually favour a >> default cell resolution of ‘1c 1c’ across the root >> container, and using (potentially fractional) >> percentages for font size. *In effect this abandons >> grids altogether.* >> >> ** >> >> I completely agree with your comment on font >> selection. I believe an implementation should be >> guide to choose a closest fit font ‘point size’ that >> fits the scaled font box, even if it is ‘slightly’ >> smaller or larger than calculated. >> >> Best regards, >> >> John >> >> *John Birch | Strategic Partnerships Manager | Screen >> *Main Line : +44 1473 831700 >> <tel:%2B44%201473%20831700> | Ext : 270 | Direct Dial >> : +44 1473 834532 <tel:%2B44%201473%20834532> >> Mobile : +44 7919 558380 <tel:%2B44%207919%20558380> >> | Fax : +44 1473 830078 >> John.Birch@screensystems.tv >> <mailto:John.Birch@screensystems.tv> | >> www.screensystems.tv <http://www.screensystems.tv> | >> https://twitter.com/screensystems >> <https://twitter.com/screensystems> >> >> *Visit us at >> SMPTE conference & exhibition, Stand G35, Sydney >> Exhibition Centre, Darling Harbour, 23-26th July* >> >> *P**Before printing, think about the environment* >> >> *From:*Nigel Megitt [mailto:nigel.megitt@bbc.co.uk] >> *Sent:* 02 July 2013 10:05 >> *To:* John Birch; Andreas Tai >> *Cc:* EBU-TT-D@list.ebu.ch <mailto:EBU-TT-D@list.ebu.ch> >> *Subject:* Re: [EBU-TT-D] Updated list of proposed >> TTML features >> >> It's been interesting to read this thread on >> returning from holiday. A few thoughts from me: >> >> ?The 'elephant in the room' that everyone has been >> politely avoiding is that the cell resolution grid is >> derived from pre-existing standards that carry the >> emotional baggage of 'this is what we're used to and >> therefore like'. In the US it was convenient to >> choose one cell resolution, presumably to make >> translating from existing documents easier (I don't >> know the exact reasons). In much of the rest of the >> world a different cell resolution has historically >> been used, so the US choice is somewhat less >> convenient. If we're interested in driving adoption >> then we have to understand the negative impact of >> sticking with the US resolution as a default, >> especially if we then put barriers in the way to >> changing it on a document by document basis. The >> simple maths described earlier shows that this is not >> a technical issue but a perception problem. >> >> ?However there is also a technical problem: If >> authors also wish to use cell resolution for >> positioning, perhaps to make downstream conversion to >> teletext subtitles straightforward (still likely to >> be in use in a lot of countries for several years), >> then the choice of cell resolution becomes a >> significant constraint. In this case the 32 by 15 >> grid would be very unhelpful indeed for anyone >> targeting a 40 by 24 grid downstream. Similarly it >> would be inconvenient the other way around. I think >> we do need to consider this 'stepping stone' use case >> even though it's not where we want to end up, i.e. >> without the dependency on legacy representations for >> subtitles. >> >> ?Three strategies that might make it equally >> convenient for both 'histories' are, in no particular >> order: >> >> oA) Create a new initial cell resolution that has >> integer multiples of both current grids, which would >> be 32x40 by 15x24 = 1280 by 360, to allow an equally >> complex or simple mapping from whatever prior >> standard has been in use, anywhere. >> >> oB) Abandon grids altogether and relate font size >> directly to the root container dimension. This would >> make the 'stepping stone' use case described above >> more complicated but still feasible. >> >> oC) Require the cell grid to be explicitly specified >> if used directly or by implication, i.e. make the >> concept of initial value carry no meaning. So if >> fontSize is not specified, a cell resolution for the >> root container *must* be specified, or alternatively >> is a fontSize is specified by not in units of c and >> cell resolution is not used for positioning purposes >> elsewhere in the document then the cell resolution >> may be omitted as it isn't used anywhere. >> >> ?I can't see how in a global context we could require >> that the root cell resolution is only permitted to >> have a single value, be it 32 by 15 or 40 by 24 or >> anything else, except perhaps for 1 by 1 as the >> mechanism for abandoning grids altogether. >> >> Something else to note: >> >> ?Typographical scaling of fonts is not >> straightforward, and can't be done linearly without >> impacting readability: the use of percentages >> suggests that an implementation might use a single >> master font and scale it. We should be clear that, >> regardless of the mechanism for specifying the >> EM-square size (ultimately to be in pixels), the font >> size is a guide for the implementation to select an >> appropriate font to fit that box. >> >> Kind regards, >> >> Nigel >> >> > > > -- > ------------------------------------------------ > Andreas Tai > Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH > R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR > Floriansmuehlstrasse 60, D-80939 Munich, Germany > > Phone:+49 89 32399-389 <tel:%2B49%2089%2032399-389> | Fax: +49 89 32399-200 > http:www.irt.de <http://www.irt.de> | Email:tai@irt.de <mailto:tai@irt.de> > ------------------------------------------------ > > registration court& managing director: > Munich Commercial, RegNo. B 5191 > Dr. Klaus Illgner-Fehns > ------------------------------------------------ > > -- ------------------------------------------------ Andreas Tai Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR Floriansmuehlstrasse 60, D-80939 Munich, Germany Phone: +49 89 32399-389 | Fax: +49 89 32399-200 http: www.irt.de | Email: tai@irt.de ------------------------------------------------ registration court& managing director: Munich Commercial, RegNo. B 5191 Dr. Klaus Illgner-Fehns ------------------------------------------------
Received on Tuesday, 16 July 2013 17:38:47 UTC