M>>Любой вордовский документ — довольно сложная структура. Вот я не верю, что кто-то в здравом уме будет ручками генерировать ХМЛ, соответствующий этой структуре. Будут пользоваться или COM-интерфейсами, как и раньше, или использовать компоненты сторонних разработчиков, которым платят за то, чтобы в этой структуре разобраться.

L>Поверь мне, с помощью xslt это делается весьма не сложно. Особенно, если структура документа не сложная.

Я знаю, что с помощью XSLT это не сложно Но если их формат будет хоть отдаленно напоминать HTML, который их же инструменты генерируют из документов, то увольте

Здравствуйте, Cyberax, Вы писали:

C>Берешь какой-нибудь документ, открываешь, делаешь Tools->Track changes и
C>попробуй поизменять чего-нибудь в документе.

Хе-хе. Помницца, когда выяснилось, что в экселе 2000 после включения режима совместной работы втихую пропадают(!) листы, сразу перехотелось использовать любые "интересные и нужные штуки"

Здравствуйте, Mamut, Вы писали:
M>Я знаю, что с помощью XSLT это не сложно Но если их формат будет хоть отдаленно напоминать HTML, который их же инструменты генерируют из документов, то увольте

HTML — внешний для ворда формат, поэтому и неудивительно, что он так сохраняет.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Хе-хе. Помницца, когда выяснилось, что в экселе 2000 после включения режима совместной работы втихую пропадают(!) листы, сразу перехотелось использовать любые "интересные и нужные штуки"

Дык, они и сейчас втихую пропадают иногда...

L>Здравствуйте, Mamut, Вы писали:
M>>Я знаю, что с помощью XSLT это не сложно Но если их формат будет хоть отдаленно напоминать HTML, который их же инструменты генерируют из документов, то увольте

L>HTML — внешний для ворда формат, поэтому и неудивительно, что он так сохраняет.

Я не уверен, что XML является таким уж прямо внутренним. Особенно для документа со сложной структурой. А сложная структура — это уже любая страница из, допустим, PDF документации к ColdFusion on Wheels потому что там есть:

— заголовки
— шрифт разных стилей
— embedded изображения
— футеры

Вместо того, чтобы разбираться, как это все представлено в новом формате, 99% разработчиков просто будет работать с Вордом через COM или через решения оставшегося 1% процента разработчиков (у которых или слишком много времени или им слишком хорошо платят для того, чтобы во всем этом разбираться)

О! PDF! Как я мог забыть! Это же формат еще легче, чем XML. Это просто текствоый формат с легкой и ясной разметкой

5-я спецификация формата PDF весит почти 7 мегабайт и содержит 1236 страниц. Уверенности, что XML-формат от МС будет короче и легче нет никакой. И на кой ляд он тогда сдался? Кроме, как маркетингового хода я в этом абсолютно ничего не вижу.

Здравствуйте, Mamut, Вы писали:

M>Вместо того, чтобы разбираться, как это все представлено в новом формате, 99% разработчиков просто будет работать с Вордом через COM или через решения оставшегося 1% процента разработчиков (у которых или слишком много времени или им слишком хорошо платят для того, чтобы во всем этом разбираться)

Для того чтобы генерить через xslt, поверь разбираться во всем формате совершенно излишне, в отличии от работы через COM.
Кроме того решение через COM мало того что дороже, оно еще и менее безопасно и более ресурсоемко. Нафик, нафик.

M>О! PDF! Как я мог забыть! Это же формат еще легче, чем XML. Это просто текствоый формат с легкой и ясной разметкой

Ну уж нет. Уж лучше тогда сразу в картинку.

M>5-я спецификация формата PDF весит почти 7 мегабайт и содержит 1236 страниц. Уверенности, что XML-формат от МС будет короче и легче нет никакой. И на кой ляд он тогда сдался? Кроме, как маркетингового хода я в этом абсолютно ничего не вижу.

Ты о чем сейчас говоришь? Что значит "будет". Он уже 4 года как есть.

M>>Вместо того, чтобы разбираться, как это все представлено в новом формате, 99% разработчиков просто будет работать с Вордом через COM или через решения оставшегося 1% процента разработчиков (у которых или слишком много времени или им слишком хорошо платят для того, чтобы во всем этом разбираться)

L>Для того чтобы генерить через xslt, поверь разбираться во всем формате совершенно излишне,

Ээээ. Не понял для того, чтобы делать <xsl:apply-templateы> нужно все же понимать из куда во что перегонять Тут без знания форматов не обойтись. (например, как, не зная формата WordprocessingML конвертировать что-нить в пример в конце?)

L>в отличии от работы через COM.
L>Кроме того решение через COM мало того что дороже, оно еще и менее безопасно и более ресурсоемко. Нафик, нафик.



M>>О! PDF! Как я мог забыть! Это же формат еще легче, чем XML. Это просто текствоый формат с легкой и ясной разметкой

L>Ну уж нет. Уж лучше тогда сразу в картинку.



M>>5-я спецификация формата PDF весит почти 7 мегабайт и содержит 1236 страниц. Уверенности, что XML-формат от МС будет короче и легче нет никакой. И на кой ляд он тогда сдался? Кроме, как маркетингового хода я в этом абсолютно ничего не вижу.

L>Ты о чем сейчас говоришь? Что значит "будет". Он уже 4 года как есть.

Блин, если б не Гугл, в жизни бы не нашел

Оооо. ООООО..... Я в экстазе Из всей документации — только схемы XSD и автоматом сгенеренный на их основе CHM А, нет, что-то есть... Посмотрим, посмотрим...

Бегло оглядывая взором wordnet.xsd (спецификация для XML Document 2003, 334 килобайта текста) бросаются в глаза, например, следующие элементы:

signedTwipsMeasureProperty
Defines a property that uses a measurement in twips (twentieths of a point, 1/1440 of an inch) that can be positive or negative.

heightRuleType
Specifies how height (h) should be interpreted.

tabJCValue
Defines tab-justification settings.

Это из простых. А там еще есть коллекции — например pBdrElt, tabsElt, listPrElt и так далее. Как с ними работать — ваще непонятно

Ладно, возьмемся за документацию. Легкий пример на вскидку (в CHM — это Word -> Concepts):

<w:p>
    <w:pPr>
        <w:listPr>
            <w:ilvl w:val="0" /> 
            <w:ilfo w:val="2" /> 
        </w:listPr>
    </w:pPr>
    <w:r>
        <w:t>Types of Web sites</w:t> 
    </w:r>
</w:p>
<w:p>
    <w:pPr>
        <w:listPr>
            <w:ilvl w:val="1" /> 
            <w:ilfo w:val="2" /> 
        </w:listPr>
    </w:pPr>
    <w:r>
        <w:t>Applications</w:t> 
    </w:r>
</w:p>
<w:p>
    <w:pPr>
        <w:listPr>
            <w:ilvl w:val="1" /> 
            <w:ilfo w:val="2" /> 
        </w:listPr>
    </w:pPr>
    <w:r>
        <w:t>Content</w:t> 
    </w:r>
</w:p>

В вышеприведенном коде у нас находится три списка. Но разобраться в них без поллитры нельзя. Никак. Это я вам серьезно говорю О том, как будет выглядеть предложенный мною пример из Coldfusion on Wheels я вообще боюсь думать

Что, в общем, возвращает меня к исходному тезису. Поддержка XML — не более, чем маркетинговый ход, потму что _напрямую_ с этим форматом работать никто и никогда не будет (за исключением ребят из OpenOffice.org и десятка разработчиков различных комерческих компонентов). Все остальные будут работать с этим делом через COM

ЗЫ. А документация по новому формату, по сравнению с Адобовской по PDF, полный отстой. Они бы XML Spy, что ли, использовали бы для генерации документации

Здравствуйте, Mamut, Вы писали:

Лень комментировать, просто напишу как делаем мы.

1. Бизнес-аналитик присылает отчет в виду вордового документа. Говорит — хочу чтобы было так, как в документе.
2. Разработчик открывает его в ворде и говорит "Сохрани в xml".
3. Далее в любимом xml редакторе открываешь этот документ и локализуешь те места, которые должны быть заполнены приложением (таблицы, списки, поля, е.т.с).
4. Локализовав эти места, разработчик, путем простейшей магии переводит это xml-документ в xslt-аналог.
5. Вуаля, преобразование готово.

И заметь, никаких знаний о том, что именн значит w:ilvl и какие атрибуты ил дочерние элементы у нее могут быть не понадобилось. Так же как впрочем и знания объектной модели ворда.

Ваш ход сударь, теперь расскажите как вы будете генерить через автоматизацию. С удовольствием послушаю.

Здравствуйте, Mamut, Вы писали:

M>Что, в общем, возвращает меня к исходному тезису. Поддержка XML — не более, чем маркетинговый ход, потму что _напрямую_ с этим форматом работать никто и никогда не будет (за исключением ребят из OpenOffice.org и десятка разработчиков различных комерческих компонентов). Все остальные будут работать с этим делом через COM

Кстаати...
А ведь это второе дыхание ОО! Микрософтовцы промахнулись xml формат то открыт и теперь (когда ребята из OpenOffice.org разберутся) больше не будет проблем с совместимостью документов. Во всяком случае я очень на это надеюсь.

Здравствуйте, Lloyd, Вы писали:

L>Ваш ход сударь, теперь расскажите как вы будете генерить через автоматизацию. С удовольствием послушаю.

Я скажу толлько одно: Сохрани документ в html и поразбирайся в нем.

Здравствуйте, Sheridan, Вы писали:

L>>Ваш ход сударь, теперь расскажите как вы будете генерить через автоматизацию. С удовольствием послушаю.

S>Я скажу толлько одно: Сохрани документ в html и поразбирайся в нем.

Не, ты не увиливай. Расскажи, как ты будешь делать с автоматизацией.

Здравствуйте, Lloyd, Вы писали:

L>Не, ты не увиливай. Расскажи, как ты будешь делать с автоматизацией.

Я лучше в хтмл сохраню. Наверняка проще.

Здравствуйте, Sheridan, Вы писали:

L>>Не, ты не увиливай. Расскажи, как ты будешь делать с автоматизацией.
S>Я лучше в хтмл сохраню. Наверняка проще.
Ну сохраняй. Хозяин — барин. Только мне будет очень интересно, как будут работать header-ы и footer-ы, а также как будут сохраняться картинки.

Здравствуйте, Lloyd, Вы писали:

L>Ну сохраняй. Хозяин — барин. Только мне будет очень интересно, как будут работать header-ы и footer-ы, а также как будут сохраняться картинки.

Достаточно применить описаный выше метод: сохранить с неадерами, футерами и картиниками и посмотреть как надо действовать...

Здравствуйте, Sheridan, Вы писали:

S>А ведь это второе дыхание ОО! Микрософтовцы промахнулись xml формат то открыт и теперь ...

Тут надо еще понять про какой из них Mamut речь ведет. ODF или что-то подобное от М$?
Форматы то разные, как и их спецификации.

Здравствуйте, Mamut, Вы писали:

M>>>О! PDF! Как я мог забыть! Это же формат еще легче, чем XML. Это просто текствоый формат с легкой и ясной разметкой

чем не устраивает PDF?
помнится его даже некоторые принтеры знают как подной, вместо PS.

M>Ладно, возьмемся за документацию. Легкий пример на вскидку (в CHM — это Word -> Concepts):
[skip]
M>В вышеприведенном коде у нас находится три списка. Но разобраться в них без поллитры нельзя. Никак. Это я вам серьезно говорю О том, как будет выглядеть предложенный мною пример из Coldfusion on Wheels я вообще боюсь думать

оно автогенеренное? я полагаю из МС и взято?
хреновый пример. с тем же успехом можно показать что HTML -- г-но, потому что ворд свои документы сохряняет в совершенно нечитабельном виде

M>>>Вместо того, чтобы разбираться, как это все представлено в новом формате, 99% разработчиков просто будет работать с Вордом через COM или через решения оставшегося 1% процента разработчиков (у которых или слишком много времени или им слишком хорошо платят для того, чтобы во всем этом разбираться)
...
M>Что, в общем, возвращает меня к исходному тезису. Поддержка XML — не более, чем маркетинговый ход, потму что _напрямую_ с этим форматом работать никто и никогда не будет (за исключением ребят из OpenOffice.org и десятка разработчиков различных комерческих компонентов). Все остальные будут работать с этим делом через COM

глупость написана. написана человеком, который пишет исключительно для виндовс и не очень хорошо себе предсавляет что такое открытое по с открытой документацией, что оно из себя представляет и для чего оно такое надо.

L>1. Бизнес-аналитик присылает отчет в виду вордового документа. Говорит — хочу чтобы было так, как в документе.
L>2. Разработчик открывает его в ворде и говорит "Сохрани в xml".
L>3. Далее в любимом xml редакторе открываешь этот документ и локализуешь те места, которые должны быть заполнены приложением (таблицы, списки, поля, е.т.с).
L>4. Локализовав эти места, разработчик, путем простейшей магии переводит это xml-документ в xslt-аналог.
L>5. Вуаля, преобразование готово.

Разве что так Сдаюсь

S>>А ведь это второе дыхание ОО! Микрософтовцы промахнулись xml формат то открыт и теперь ...

0>Тут надо еще понять про какой из них Mamut речь ведет. ODF или что-то подобное от М$?
0>Форматы то разные, как и их спецификации.

О Микрософтовском детище. Но спецификация открыта. Так что при желании можно научиться открывать/конвертировать в МС формат без потерь.

Однако! PDF формат тоже открыт всем, а вот абсолютно грамотных реализаций его — кот наплакал. Потому что довольно сложно

M>>>>О! PDF! Как я мог забыть! Это же формат еще легче, чем XML. Это просто текствоый формат с легкой и ясной разметкой

_>чем не устраивает PDF?
_>помнится его даже некоторые принтеры знают как подной, вместо PS.

Устраивает всем Я о том, что, несмотря на весьма неплохую документацию, разобраться в устройстве PDF все же весьма и весьма непросто.

M>>Ладно, возьмемся за документацию. Легкий пример на вскидку (в CHM — это Word -> Concepts):
_>[skip]
M>>В вышеприведенном коде у нас находится три списка. Но разобраться в них без поллитры нельзя. Никак. Это я вам серьезно говорю О том, как будет выглядеть предложенный мною пример из Coldfusion on Wheels я вообще боюсь думать

_>оно автогенеренное? я полагаю из МС и взято?

Видно, что документация по новым файловым форматам сгенеренна напрямую из XSD. Дополнительно, есть что-то вроде туториала.

_>хреновый пример. с тем же успехом можно показать что HTML -- г-но, потому что ворд свои документы сохряняет в совершенно нечитабельном виде



Не, я о том, что без поллитры в новом формате все равно не разберешься, будь он хоть трижды описан и документируем.

M>>>>Вместо того, чтобы разбираться, как это все представлено в новом формате, 99% разработчиков просто будет работать с Вордом через COM или через решения оставшегося 1% процента разработчиков (у которых или слишком много времени или им слишком хорошо платят для того, чтобы во всем этом разбираться)
_>...
M>>Что, в общем, возвращает меня к исходному тезису. Поддержка XML — не более, чем маркетинговый ход, потму что _напрямую_ с этим форматом работать никто и никогда не будет (за исключением ребят из OpenOffice.org и десятка разработчиков различных комерческих компонентов). Все остальные будут работать с этим делом через COM

_>глупость написана. написана человеком, который пишет исключительно для виндовс и не очень хорошо себе предсавляет что такое открытое по с открытой документацией, что оно из себя представляет и для чего оно такое надо.

Эээ. Открытое ПО открытым ПО. И открытая документация открытой документацией. Я вполне себе представляю, что это такое, несмотря на то, что пишу таки да, под винду

Но. И это очень большое но! От того, что новый микрософтовский файловый формат открыт, мне ни холодно ни жарко. Так же как мне ни холодно нижарко от того, что PDF — тоже открытый формат (и подольше, чем микрософтовский). Потому что знаниме формата файла нужно крайне ограниченному количеству разработчиков — идеалистам (OpenSource ) и тем, кому за это платят деньги (разработчики коммерческих компонентов для работы с этим форматом). Тем более, что этот формат будет изначально очень сложным для полного понимания и усвоения. Времени на его изучение ни у меня ни у Вас, скорее всего не будет. И тратить мы время будем на поиски готовых библиотек или на работу с Вордом по-старинке, через COM

То есть _принципиальной_ разницы между старым .DOC и новым .DOCX (или как он там называется) я не вижу. Вместо того, чтобы кучу бабок на разработку нового формата выкидывать, могли бы просто спецификацию .DOC выпустить, благо она наверняка намного подробнее документирована (внутри компании — точно).

Здравствуйте, XPGeeK, Вы писали:

XPG>А у кого стоит лицензионный M$ Office?
У многих.
XPG>К сведению OOffice распостраняется бесплатно и содержит функционал не хуже, а то и лучше M$ Office.
Ну-ну.
XPG>Например можно ли одним кликом отправить редактируемый файл в MSWord по почте
да
XPG>или сконвертировать его в PDF?
да, если стоит Acrobat.