давай определяться. накидаем общий план. будем конкретней. 
этапы чуть изменил.

я ПРЕДЛАГАЮ:
1 этап: разделение на логические части.
полностью убираем из страницы банеры и комментарии (по желанию пользователя).
затем убираем inline-стили, inline-script. в случае стилей - создаем классы, в случае скриптов - привязка по ID. после разделения проверяем страницу на выполнение скриптов. если без ошибок, то все ok. если все-таки скрипт привязали к иерархии, то чуть-чуть сложнее. тогда иерархию не будем трогать. 

итак, первый этап как реализуется.
с помощью JSCRIPT проходим по нодам.
1) убираем атрибуты, имеющие аналогичное значение на CSS, типа как CELLPADDING, CELLSPACING тэга TABLE.
2) создаем классы из инлайн-стилей
3) убираем инлайн-скрипты
4) закрываем незакрытые тэги.
5) приводим тэги согласно XML ( <br /> <img />), разбираемся с перекрываемостью. тем самым, избавляем страницу от ошибок.
6) убираем лишний контент: комментарии, в CSS свойства, начинающиеся на mso-... ( - от MsWord)

что имеем после 1го этапа?
3 строго отдельных части: STYLE, SCRIPT, BODY
иерархия пока не изменена.

2 этап - думаю, что лучше будет, разбирать последовательности тэгов и стилей. это и есть анализатор.

сложно, очень сложно.. 
тут в первую очередь надо определиться с самой версткой. подумаем над каждым элементом. тело документа будет состоять из 
1) блоков (DIV)  роль блоков - позиционирование (мне кажется только это, если нет поправь меня, + AJAX?)
2) таблицы
3) текстовые элементы: заголовки 6 уровней, параграфы
      в параграфы входят
  а) списки
  б) strong, i (хотя от него отказались W3C) и span (для особых стилей)
  в) анкоры и ссылки
4) инлайн-фреймы.

каждый элемент должен выполнять строго отведенную ему роль.
сначала меняем лишние тэги (например, u на span с классом), неудовлетворяющие нас.
это была подготовка.

тут нужно понять,  что нужно пользователю. варианты:
1. упростить структуру тэгов, не изменив отображение (вид) (или в допустимых рамках).
2. сделать текст читабельным, а сам дизайн - приятным на глаз
3. выделить полезное содержание

в случае 2го варианта, нужны заранее созданные стили + избавиться от горизонтальной прокрутки полностью (или учитывать исключения)

1й вариант сложноватый.
что мы имеем.. до фига тэгов с классами. цель - возможное их сокращение и приведение по правилам нашей верстки.
1) надо рассмотреть общее содержимое классов дочерних тэгов одного уровня в иерархии и объединить их. 
2) очень часто при создании в редакторах разработчики по нелепости могут выделить часть текста другим похожим шрифтом на должный. надо убирать лишние шрифты.
3) тоже самое относится к выбору цвета.

пока все было по исправлению верстки.. теперь по теме

3й вариант. добывание полезной информации.. - 
полезность -  понятие относительное!
я думаю , что лучший подход будет таков:
пользователь выделяет мышкой тот контент, который ему нужен. те, прямоугольники, которые не попали, обрабатывать/вносить в заключительную верстку не будем.
если несколько страниц с одного сайта и изначальная верстка хоть как-то соответствует шаблону, то программа может "учиться". по примеру 1-2х страниц, работать над остальной частью.


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

Понадобилось выполнять цикл, включающий фрагмент кода, размещённый в шаблоне. Поэтому вызываю функцию с текстом-кодом. Теперь осталось выявить закономерности в используемых шаблонах, чтобы выработать компактную функцию. Цель в том, чтобы шаблон смотрелся наглядно и естественно, примерно как математический знак суммы.
Конечно, я ориентируюсь на реальные задачи. Сначала задаю структуру, потом запускаю распознаватель. По результатам джб видно, удачна структура или нет. Но в распознаватель надо включить постоянные процедуры типа игнорирования пробелов, чтобы не прописывать каждый раз их явно. Тогда распознавателем будет удобно пользоваться, и, кроме того, он будет показывать ошибки и отклонения от структуры.

Результаты первого действия  выложу в другую тему после того как напишу.

Добавлено @ 12:07 
это первое направление

Идея баннерорезки, которую вы тут развили - она тоже парсер с правилами, алгоритм может использоваться, но это обычно делают в прокси, не на JS. 

Хотя, есть идея работать по DOM внутри сгенерированной страницы (процедура внедряется через прокси, если это в онлайне вырезают баннеры "на лету" или включается вручную строкой вызова скрипта, если идёт анализ страниц для извлекания информации по шаблону.
JSman, люди уже писали программы выбразывания мусора, сделанного в Frontpage. Если поискать по ресурсам программ, найдётся. Аналогичное должно существовать и для Word.

Но переверстать произвольный текст в правильный - сильно неопределённая задача. Нужно сначала проработат всю технику перевода (что невозможно по объёму исследования поддержки глюков разных версий бр-ров), потом расписывать строение анализатора. Упрощённая версия - ограничиваемся "каноническими" методами, которые тоже надо выделить из опыта правильной вёрстки, которые будут одинаково показываться в бр-рах. Но не исключено, что придёт новая версия и всё испортит.

Тут надо придерживаться работы по доктайпам, и, чтобы действие было признано сообществом, работа должна постоянно ссылаться на стандарты и понимать дух их развития. Если это будет, она может повлиять на выработку правильной вёрстки вообще, а так - одна из версий.

Из режимов я бы добавил к приятному на глаз ещё суперприятный на глаз . Дельное предложение.
Приятность надо сначала вычислить формулой, потом написать операторы  итераций, чтобы потом применить метод Рунге-Кутта .

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

В этом деле появилось ещё 1 направление (тоже опишу в отдельной теме) - вытащить часть вёрстки в JavaScript, чтобы брать её из кешированного скриптового файла. А то, что останется на HTML, должночитаться поисковиками и браузерами с отключённым  JS.
Хороший вариант визуализации выбора контента. Правда, это уже 3-я часть программы, отдельный модуль. Изначально я предполагаю писать шаблон. Потом - подумать, как автоматизировать писание шаблона в визуальной оболочке.

Как? Нука обрисуй алгоритм, по которому можно с большой долей вероятности сказать баннер перед нами или нет. Конечно большинство баннеров имеют фиксированный размер, если работать с DOM деревом, но тогда не известно как он был туда вставлен (какой скрупт). Если парсим текст сами, то как узнать что есть баннер, ведь это почти всегда замороченный JS.



В DOM дереве не существует не закрытых тегов и т.п. дерево уже разобрано, а вот при записи можно конечно привести всё к XHTML. ИМХО задача левая для JS, это не язык, на котором удобно писать анализаторы.




Тебя дизайнеры расстреляют 


Нет, фактически весь документ может быть отображён узлами единого типа, но с разными стилями. div это блочный элемент, т.е. имеет контейнер. Прочти CSS2 спецификацию, многое узнаешь о строении и отрисовке документов.


Как? Эвристика? А может нейронную сеть лет так сотню обучать, тогда может процент ошибок будеть меньше...


Горизонтальная прокрутка - есть результат фиксированных размеров, не влезающих в экран. "Убрать" так просто нельзя, не изменив внешнего вида (буквально страница развалиться).

Добавлено @ 20:15 

Вот это хорошее уточнение, значит ищем по шаблону. Наиболее просто для XML документов, это через XSLT выбрать инфу в точно известных узлах (копировать можно целые поддеревья) в новый документ. Баннеры и прочий меяющийся шум в документе не будет мешать до тех пор, пока XPath выборки указывают на требуемые ноды, т.е. структура документа в целом не меняеться.

Такой шаблон придёться делать для каждой группы документов со своей уникальной структурой. Для юзера удобной шкуркой будет выделение мышью необходимого контента, как уже говорил JSman.

Sardar, документы, из которых придётся что-то извлекать, обычно далеко не xml - справочники, книги, образы сайтов. С дизайном, свёрстанным вручную.

полностью убираем из страницы баннеры [/quote](Если пытаться через JS парсить реальные страницы, прежде прокси-сервером надо удалять содержимое фреймов чужих доменов, иначе не будет работать.)
[quote=Sardar, 26.8.2006,  20:06, post834438]

есть банеры 3х видов: IMG, IFRAME, ActiveXObject (Flash)

IMG делают ссылку на другой хост.
IFRAME - полностью состоит из ссылок и картинок на другой хост (Google)
Flash - вся канва перекрыта объектом button, при клике ведущий, опять же, на другой хост. доступ к объектам через свойства и тд

можно также учитывать их расположение на странице: до/после основного содержимого, отдельно сбоку странички. 

это вообще отдельная тема.



ну ты меня не понял. на этом этапе основной целью является переделка верстки. анализатор по этой части написать можно. даже на регЭксп c js



ты сам знаешь, что красивые и удобные страницы пользователь не захочет править. это лишь дополнительная опция по анализу шрифта и цвета. с mso разговор КААРОТКИЙ. тут понятно.


я замечательно знаю CSS, но, опять же, я же не просто так написал типа по-незнанию.
есть тэги, играющие по нашим правилам.
вот, что я писал

мы весь обрабатываемый контент подводим по нашим правилам.
типа текст - это совокупность заголовков и параграфов. а не дивов со спанами. надо его, текст, стандартизовать, то есть вставить тэги, которые бы следовало написать.



по 3му ясно - это выделение мышкой.

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

1е - последовательность тэгов! нужно сводить до минимума положение "контейнер в контейнере" (для див актуально). сложно,конечно, но интересно. и есть другие ситуации.


да. но для боди в некоторых случаях подойдет.

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

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



Это сообщение отредактировал(а) JSman - 26.8.2006, 23:19

пора определять этапы, товарищи!  

ОК, ладно, чисто ради прикола в свободное время:

• берём любой html парсер, их много
• берём любой CSS парсер, их тоже не мало
• поверх API либ третьих лиц строим свои классы для дерева с одним типом узла, но разными CSS стилями.
• выдаём API для фильтров, что будут перебирать дерево в п.3, модифицироват его. Экспериментируем с идеями.

На всё может уйти месяц. Если запользовать что то подобное http://html.xamjwg.org/cobra.jsp то меньше, но с кодом придёться основательно разобраться. Естественно всё на Java, JS тут физически не возможен 

На досуге покопаюсь в кобре.

для анализа чужих кодов, я же раза 2 об этом написал.

или возможен )))

давайте так (Sardar, 12345c) , пока начнем что-нибудь, потом покажем, совместим, что возможно, подумаем. мне надо хоть в Москву приехать, а то Сочи, море, пляж, отдых в общем. с 5го числа серьезно займусь.

для меня тут и перлом пахнет, дельфи, жс. посмотрим.

JSman, открывай новую тему, выкладывай конкретные маленькие задачи (например парсер CSS в дерево аттрибутов). Дизайн всей этой софтины сам придумай, я лишь с кодом на конкретные задачи в свободное время помогу.