<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Aptos;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle21
{mso-style-type:personal-compose;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:11.0pt;
font-family:"Aptos",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:65424761;
mso-list-template-ids:-1354715666;}
@list l0:level1
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">It may be worth considering the implications a bit more in cases of _<i>arrays</i>_ of offsets. For example, in MultipleSubstFormat2, changing coverageOffset from Offset24 to Offset32 adds one byte to the
size, but changing sequenceOffsets[] from Offset24 to Offset32 adds sequenceCount bytes to the size. Similarly for AlternateSubstFormat2 and alternateSetOffests[].
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">In these two cases, it’s possible these lookup types might not be heavily used in fonts today, so the impact might not be significant. (That’s an empirical question; it could be checked against some large
collections such as Google Fonts.) <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">But I suspect ligature substitutions are fairly heavily used. One could investigate what are typical or worst-case values for ligatureSetCount (= coverage size) or for ligatureCount (number of ligatures with
the same starting glyph). A large ligatureSetCount doesn’t present a perf concern since the LigatureSet array is in coverage order and coverage can be searched quickly. On the other hand with a large ligatureSetCount, the size impact of changing to Offset32
would be larger.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">As Behdad pointed out in the meeting, having a large ligatureCount will run into processing perf issues since a fast search over the Ligature table array isn’t possible and they must be scanned in order. What’s
the implication? On the one hand, one might argue that Offset32 isn’t needed for ligatureOffsets; but on the other hand, it might be argued that the impact of Offset32 for ligatureOffsets is limited since ligatureCount isn’t ever likely to be large.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Similar thinking applies to (chaining) contextual substitutions: the rule sets are in coverage order and can be scanned quickly, so there isn’t a processing perf reason to limit the count, though a large count
would mean a larger size impact using Offset32. But within a rule set, rules have to be scanned in order hence there is a processing perf reason to limit the rule count.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">One of the concerns MS folk raised is the potential confusion for developers mixing up offset sizes. The suggestion was that using Offset24 in more places would add to that concern. Of course, if we define
formats that use Offset32 for some members but Offset24 for others, that would add further to that concern.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Pros and cons… I haven’t formulated a definite opinion on sub-subtable offsets.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Peter<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Behdad Esfahbod <behdad@behdad.org>
<br>
<b>Sent:</b> Sunday, December 17, 2023 7:21 PM<br>
<b>To:</b> Sergey Malkin <sergeym@microsoft.com><br>
<b>Cc:</b> Peter Constable <pconstable@microsoft.com>; Liam Quin <liam@fromoldbooks.org>; MPEG OT Spec list <mpeg-otspec@lists.aau.at><br>
<b>Subject:</b> Re: [EXTERNAL] Re: [MPEG-OTSPEC] comments wrt wide glyph ID proposal<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">I bumped the subtable-level offsets to Offset32. But I need direction about the sub-subtable-level offsets. They still pose some of the same "problems". That is, you cannot have all of the 24bit glyphs in the same subtable. I can address
that by upgrading most of the Offset24's (now mostly in arrays) to Offset32.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">How do people feel about this?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">behdad<br>
<a href="http://behdad.org/" target="_blank">http://behdad.org/</a><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Tue, Dec 12, 2023 at 12:02<span style="font-family:"Arial",sans-serif"> </span>PM Sergey Malkin <<a href="mailto:sergeym@microsoft.com">sergeym@microsoft.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"><i><span style="font-size:11.5pt;color:black">> In those extreme cases the subtable can be broken down into more, like we currently do with 16bit offsets. I don't think it's a realistic limitation, but happy to bump all Coverage and ClassDef
offsets to 32bit.</span></i><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.5pt;color:black">Fo me, main reason would be not overflow but potential incovenience because of too many formats. We have a mix of 16-24-32 bit offsets without clear reason why to one over another (and no real
explanation what future additions should use). I'll have to look up the spec every time I want to read one or another. Saving one byte is not worth the trouble.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.5pt;color:black">Thanks</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.5pt;color:black">Sergey</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="98%" align="center">
</div>
<div id="m_-2762021842492429935divRplyFwdMsg">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"> mpeg-otspec <<a href="mailto:mpeg-otspec-bounces@lists.aau.at" target="_blank">mpeg-otspec-bounces@lists.aau.at</a>>
on behalf of Behdad Esfahbod <<a href="mailto:behdad@behdad.org" target="_blank">behdad@behdad.org</a>><br>
<b>Sent:</b> Tuesday, December 12, 2023 4:39 AM<br>
<b>To:</b> Peter Constable <<a href="mailto:pconstable@microsoft.com" target="_blank">pconstable@microsoft.com</a>>; Liam Quin <<a href="mailto:liam@fromoldbooks.org" target="_blank">liam@fromoldbooks.org</a>><br>
<b>Cc:</b> MPEG OT Spec list <<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a>><br>
<b>Subject:</b> [EXTERNAL] Re: [MPEG-OTSPEC] comments wrt wide glyph ID proposal</span>
<o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Thanks Peter for the excellent feedback. <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Comments inline.<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, Dec 11, 2023 at 7:54<span style="font-family:"Arial",sans-serif"> </span>PM Peter Constable <<a href="mailto:pconstable@microsoft.com" target="_blank">pconstable@microsoft.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p><o:p> </o:p></p>
<p><b>Hybrid narrow/wide fonts:</b><o:p></o:p></p>
<p><span lang="EN-CA">Hybrid fonts are going to be more challenging to build and maintain—much more so than hybrid COLRv0/v1. Attempting to engineer mechanisms specifically to accommodate hybrid fonts is likely to add to complexity.</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I agree it should not be the focus of the work<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p><b><span lang="EN-CA">TTCs:</span></b><o:p></o:p></p>
<p><span lang="EN-CA">A second take-away for us from thinking about hybrid fonts is that we think TTCs can provide another approach to creating hybrid fonts—one that could be easier for font developers to create and maintain. To that end, we think it would
make sense to define a v2.1 TTC header that adds numFonts2 and tableDirectoryOffsets2 members, and provide guidance that software that supports wide glyph IDs should use only these new members, ignoring numFonts and tableDirectoryOffsets. In this way, older
software could see only fonts with narrow glyph IDs, while newer software could see a distinct set of fonts without duplication.</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'd be happy to incorporate this.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p><span lang="EN-CA">This brought to my mind that, six – ten years ago (I forget the exact timeframe), there was discussion between Adobe, Apple and MS about defining a _<i>dmap</i>_ (delta cmap) table for use in TTCs: It’s very common in TTCs that there are
cmap differences, with the result that each font in the TTC must have its own cmap without any sharing of data. In CJK fonts, the cmap table is one of the largest tables (probably second only to glyf or CFF / CFF2). Moreover, in a CJK font, the majority of
mappings in a cmap table could be the same, with only a small portion of mappings being different. (E.g., in MS Gothic vs MS PGothic, all the ideograph glyphs are the same; it’s just Latins and punctuation that differ.) A dmap table would allow fonts in a
TTC to share a common base cmap table with small, font-specific dmap tables handling differences. In our discussions, we came up with formats that would work, except we hadn’t figured out how to handle format 14 cmap subtables.</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This reminds me of another idea we discussed in, I think, 2019, from Monotype to introduce a `cmap` subtable that would map individual characters to sequences of glyphs. Then the pre-composed Unicode characters wouldn't need to have their
own glyphs. Back then we dropped the idea for backwards-compat reasons. But maybe we can pick it up now?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p><b><span lang="EN-CA">COLR, MATH:</span></b><o:p></o:p></p>
<p><span lang="EN-CA">We noted that the proposal doesn’t include any integration for COLR or MATH tables. There might be several things to consider in relation to the MATH table, and we have no concern with leaving that for future consideration.</span><o:p></o:p></p>
<p><span lang="EN-CA"> </span><o:p></o:p></p>
<p><span lang="EN-CA">But COLR might not be too difficult. So, we think it’s worth discussing options:</span><o:p></o:p></p>
<ol start="1" type="a">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
<span lang="EN-CA">Postpone for future consideration.</span><o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
<span lang="EN-CA">Create a new major version — i.e., a new table tag — to design a table with wide glyph IDs (it wouldn’t need to support narrow IDs).</span><o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
<span lang="EN-CA">Create a minor version enhancement (COLR v2) that maintains backward compatibility while adding wide support.</span><o:p></o:p></li></ol>
<p><span lang="EN-CA"> </span><o:p></o:p></p>
<p><span lang="EN-CA">The third option would need to add new offsets in the header for wide variants of base glyph and clip lists, with new BaseGlyphPaintRecord2 and ClipRecord2 formats. (There’d also need to be a new PaintGlyph format, but that will be true
regardless.)</span><o:p></o:p></p>
<p><span lang="EN-CA"> </span><o:p></o:p></p>
<p><span lang="EN-CA">We haven’t yet decided which option we prefer; we just want to get it into discussion.</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">My preference is to introduce PaintGlyph's with wide gid's without bumping the format number for now, and postpone ClipList and other enhancements to a future v2 version. Note that there exist already COLRv1 fonts that hit the 64k glyph
limit because of all the components. Those would become feasible with just a new PaintGlyph2 / PaintColrGlyph2 / etc extension and do not need the full ClipBox etc widening.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p><span lang="EN-CA"> </span><o:p></o:p></p>
<p><b><span lang="EN-CA">Max profile:</span></b><o:p></o:p></p>
<p><span lang="EN-CA">The current proposal doesn’t make any change wrt ‘maxp’, other than to say numGlyphs isn’t used for wide-GID support. In a hybrid font, it’s unclear what font developers should do with all the other maxp members: if they’re set as appropriate
for narrow GIDs, then the values may not work for wide GIDs and the app could run out of resources. On the other hand, if the values are set for wide GIDs, those can work for both narrow and wide, but for older software could lead to over-allocation of unused
resources.</span><o:p></o:p></p>
<p><span lang="EN-CA"> </span><o:p></o:p></p>
<p><span lang="EN-CA">Since we’re already considering glyf/loca and GLYF/LOCA that can exist side by side, it seems simple and clean to define a MAXP table that gets used only in conjunction with GLYF/LOCA. These tables are small, so the file size impact is
negligible.</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">How real is the use of max profile data these days? My understanding is that since the data cannot be trusted anyway, software doesn't rely on it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p><b><span lang="EN-CA">GPOS/GSUB:</span></b><o:p></o:p></p>
<p><span lang="EN-CA">It appears the proposal doesn’t yet include wide versions for common table formats that will be required (e.g., coverage). These will, of course, be needed</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm surprised by that. But you are right, them seem missing from the PDF document. <a href="mailto:liam@fromoldbooks.org" target="_blank">@Liam Quin</a> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The proposal is:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <a href="https://github.com/harfbuzz/boring-expansion-spec/issues/30" target="_blank">https://github.com/harfbuzz/boring-expansion-spec/issues/30</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p><span lang="EN-CA">This may be an opportunity to deprecate certain formats from use in wide-GID fonts. E.g., GSUB type 5 and GPOS type 7 (contextual) were effectively obsoleted when the chaining contextual formats were added. If we agreed, then Contextual
positioning / substitution subtable formats 4 – 6 wouldn’t need to be added.</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm ambivalent here. Adding them is simple enough for me and keeps consistency.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p><span lang="EN-CA">Various formats are proposed using uint24 for subtable counts and Offset24 for subtable offsets. This could turn into a real limitation. For example, consider single substitution format 4: if glyphCount were 5,592,406, then the size of
the substituteGlyphIDs[] array would exceed xFFFFFF and Offset24 for coverageOffset would not work. We’re inclined to make offsets and any counts not limited by 24-bit GIDs to be 32-bit.</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">In those extreme cases the subtable can be broken down into more, like we currently do with 16bit offsets. I don't think it's a realistic limitation, but happy to bump all Coverage and ClassDef offsets to 32bit.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">behdad<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>