» Разработка программ для обработки сканов книг

U235

Цитата:

а с его производной

Что значит, с его производной?

U235

Цитата:

Насчет Deskew'a:

Спасибо, интересно. Если руки дойдут - попробуем.

Цитата:

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

Я тоже об этом уже думал - первое, что приходит в голову - научиться со временем применять deskew не ко всей странице, а предварительно её "грубо" сегментировать, находить области с текстом, и к ним применять deskew. А то и вправду - картинки сбивают deskew с толку - это часто бывает в Кромсаторе - а в Файнридере почти никогда не бывает - возможно, ABBYY так делают - это просто предположение.


Хотелось бы продолжить насчёт структурированности: теоретически, будущая команда раработчиков могла бы состоять из 2 групп:

1. "Группа А" - физики-математики, занимающихся разработкой фундаментальных алгоритмов.

2. "Группа Б" - прикладные программисты, оформляющие найденные группой А алгоритмы в визуальные интерфейсы и вообще в конечные программы.

Это, так сказать, мысли вслух - общие теоретические соображения. Такая схема имеет важное преимущество: весь проект получает ярко выраженную образовательную направленность - по мере разработки, часть группы Б будет плавно перетекать в группу А - в результате повышения своего образовательно-квалификационного уровня.

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

monday2000
Посмотрите еще вот этот метод определения угла наклона:
http://www.leptonica.com/skew-measurement.html

Цитата:

Что значит, с его производной?

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

Цитата:

Я тоже об этом уже думал - первое, что приходит в голову - научиться со временем применять deskew не ко всей странице, а предварительно её "грубо" сегментировать, находить области с текстом, и к ним применять deskew.

Зачем? Ведь применять вращение нужно же полностью для всей страницы.. Сегментация, ИМХО, на даном этапе не нужна.
Кстати, если попадется страница, на которой ФР или SK делают неправильный deskew, то прошу выложить ее где-нибудь на обозрение, для выяснения причин.
foo

Цитата:

Посмотрите еще вот этот метод определения угла наклона:

ИМХО, на первый взгляд ничего принципиально нового, того, чего нет у "Открытого кода", не обнаружил, единственно, что кроме преобразования Радона указывается возможность использования преобразования Хаффа.

U235

Цитата:

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

Вы имеете ввиду использование Shen-Castan или Sobel edge-фильтров?


Цитата:

то прошу выложить ее где-нибудь на обозрение, для выяснения причин.

Причина как-раз таки ясна. Оба метода (имею ввиду наиболее применяемые - проекционный и Hough/Radon) являются по сути оптимизационными, т.к. ищут экстремум в нектором аккумуляторном буфере. Некоторые иллюстрации вносят большую долю в этот аккумулятор и становятся доминирующими экстремумами. Monday2000 прав, по хорошему, от них надо избавляться. Я это не стал делать по одной простой причине - это замедлит алгоритм. Я учитывал, что процент ошибок deskew из-за таких ложных наклонов ничтожен (не более 3-5 на каждые 500 страниц), а замедление, помноженное на общее количество страниц, приведет уже к значительной цифре.
Кстати, упражнение для тренировки: как скажется применение edge-фильтров на точности определения экстремума?

kontiky
Поскольку Cptn_Cook не отвечает и на вчерашний запрос по мылу из профиля, то я тут порылся в его прошлогодних файлах и решил кое-что выложить:

http://www.webfile.ru/1154077
Размер 100 кб
Файл будет доступен минимум до 01.11.2006 08:40

Это какая-то научная статья по deskew + текстовка (кусок колхозной ветки).
Думаю, что статью можно выкладывать где угодно, а вот текстовку не стоит ещё где-то публично выкладывать.

Кстати, статья в формате ps и мой Adobe Acrobat 6.0 CE Pro что-то подозрительно так ругался, когда его открывал (не мог внедрить шрифты чего-то там) и конвертировал в Pdf - поэтому я полученный Pdf не выкладываю.

Добавлено:
Эта статья и старые материалы Cptn_Cook навели меня ещё на одну мысль: а вдруг для наших целей пригодятся также и статьи на http://www.lizardtech.com/products/doc/techinfo.php ? То есть эти статьи, конечно, о формате DjVu - но а кто его знает - вдруг какие-то общие подходы окажутся едиными и могущими быть применёнными и в программе по улучшению/обрезке сканов? Статьи-то там серьёзные, научные, так что возможно, стОит их так бегло просмотреть - что там в них полезного.

Добавлено:
kontiky
Только что обнаружил - найденный Вами проект http://ocr.apmath.spbu.ru/ месяц назад реинкарнировался в новый сайт:

http://www.cr-online.ru/

Добавлено:
Полезный сайт:

http://vadkudr.boom.ru/index_rus.html


Добавлено:
Теория и практика вейвлет-преобразования

http://www.autex.spb.ru/wavelet/

Цитата:

Sobel edge-фильтров

Да, это оно.

Цитата:

Кстати, упражнение для тренировки: как скажется применение edge-фильтров на точности определения экстремума?

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

monday2000, на 7-ом диске колхоза в разделе LinuxSoftware есть исходники free GPL программки deskew. Автор - snake4d. Это, возможно, то, что Вы ищите.

U235

Цитата:

Это, возможно, то, что Вы ищите.

Залейте на Рапиду, хорошо? (Раз уж это GPL). (у меня нет колхозных дисков).

http://www.mytempdir.com/999146

U235
Спасибо! Вот что-то такое и хотелось - небольшое, простое, где реально разобраться по коду. Если попадётся нечто подобное по despeckle - тоже давайте.

Добавлено:
bolega
Вынос "в свет" идеи программы по обрезке-обработке сканов книг предлагаю залегендировать как проект для оцифровки старосоветских книг, не подпадающих под копирайт: как я понимаю, сюда относятся советские книги до, кажется, 1973 года (поправьте меня, если не прав), а также, скорее всего (тут надо уточнить) советские художественные некопирайтные книги - есть вот т.н. "всемирная библиотека" (у меня есть 70% её, и я вот не знаю - выкинуть жалко, а хранить - громоздко ).

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

Добавлено:
А полученные сканы, дескать, предполагается прогонять через web-сервис http://any2djvu.djvuzone.org/ .

При таком подходе мы всех борцов за копирайт пошлём далеко и надолго.

monday2000
Спасибо за исходники. Уже скачал.

Цитата:

Только что обнаружил - найденный Вами проект http://ocr.apmath.spbu.ru/ месяц назад реинкарнировался в новый сайт:   http://www.cr-online.ru/

Огромный вам решпект! Буду изучать. Кажется, это то что нам всем нужно...

U235

Цитата:

http://www.mytempdir.com/999146

Спасибо за исходники!

На уже известной странице http://durendal.org:8080/twiki/bin/view/Deskew/WebHome есть интересная ссылка:

Document Dewarping: http://quito.informatik.uni-kl.de/dewarp/dewarp.php

С которой можно выйти на:

IUPR Research Group http://www.iupr.org/

у которой есть интересный архив публикаций: http://pubs.iupr.org/

И ещё полезно сюда заглянуть:

http://www.iupr.org/demos

Там есть Layout Analysis: http://demo.iupr.org/layout/layout.php
и тот же Document Dewarping, но под новой ссылкой: http://demo.iupr.org/dewarp/dewarp.php

Добавлено:
Так что моя идея о структурированности разработки сама собой уточняется. Допустим, будут 2 группы разработчиков:

Группа А - те, кто:

1. Берёт статьи и пишет по ним программные реализации алгоритмов.
2. Находит в Интернете уже готовые алгоритмы и "перебивает" их под наши нужды.
3. Разрабатывает с нуля или не совсем свои собственные алгоритмы и пишет их программную реализацию.

Продукцией группы А будут служить программные реализации алгоритмов в виде как исходников, так и простейших консольных (для понятности исходников) программ.

Группа Б - те, кто:

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

Важный момент: с самого начала всем участникам проекта хорошо бы избрать единую среду разработки. Я предлагаю - Win32/FreeImage/C(C++). Это для того, чтобы все могли использовать результаты работы всех. Почему именно связка Win32/FreeImage/C(C++) ? Вроде бы это самый популярный/надёжный/низкоуровневый/обкатанный вариант. К примеру, брать язык Матлаба (как питерцы в старом варианте сайта) - неразумно, ведь таким программам для работы потребуется матлабовский движок, а значит всё равно кто-то будет "перебивать" матлабовские программы на что-то более низкоуровневое, могущее напрямую быть скомпилированным под Win32.

Группе Б я бы предложил использовать MFC - для простоты и понятности, брать .NET - менее популярно это пока. STL предлагаю не использовать - далеко не все его знают.

При такой схеме участникам группы А могут быть почти что абсолютно "безразличны" цели и задачи группы Б и наоборот - что значительно упростит разработку. Нет нужды кому-то одному упираться, рвать себе жилы, и делать всё "от и до".

Как показал опыт DjVu Small, найти людей для группы Б - не проблема - там всего нашлось 4 человека, и даже за довольно короткий срок.

Ну, и конечно, само собой - всё производимое участниками должно быть с открытыми исходниками (никакой закрытости) и, желательно, с GPL-лицензией (чтобы всё можно было оформить на sourceforge).

И тогда при грамотном подходе и должной организации мы получим "эффект Линукса" - когда большая и технически сложная система создаётся добровольцами.

Добавлено:
Возможные трудности: допустим, никто из группы Б не захочет открывать свои исходники - не беда, при условии наличия продукции от группы А (а сейчас этого нет, по крайней мере в варианте Win32/FreeImage/C(C++)) особого труда накатать своё "GUI" не составит. К тому же лично меня тут обнадёживает пример WinDjView - там же все исходники открыты.

Добавлено:
Дополнительное удобство такого структурированного подхода в том, что участникам группы А нужно будет быть программистом в самой минимальной степени - достаточно лишь знать С/С++ и уметь писать консольные Win32-приложения - что довольно просто. Им не надо даже знать MFC, к примеру.

Сделал новый раздел у себя на сайте:

http://www.djvu-soft.narod.ru/bookscanlib/

Добавлено:
У меня такой ко всем вопрос: никто не знает, существует ли CHM-версия пособия на http://www.firststeps.ru/mfc/steps/mfc1.html ?

Если не существует, то надо бы её сделать. И тогда можно будет давать её всем будущим участникам проекта. Я, к сожалению, ничего не понимаю в технологии создания CHM.

Конечно, неплохо бы и прочие разделы в CHM загнать - например, http://www.firststeps.ru/mfc/source/source1.html , http://www.firststeps.ru/mfc/msdn/msdn1.html - но это уже ИМХО не так критично.

Добавлено:
Что касается STL, то вот один человек очень сильно хвалит такую книжку:

Леен Аммерааль. STL для программистов на C++ http://www.pcports.ru/files/lib/stl.rar (1,2 МБ)

Цитата:

Познакомившись с STL, я был в восторге от ее возможностей. Учился я именно по этой книге, и несмотря на то, что она 1999 года выпуска, до сих пор ни чего лучше по данной тематике я не нашел. Обязательно надо прочесть и использовать

monday2000

Цитата:

У меня такой ко всем вопрос: никто не знает, существует ли CHM-версия пособия

Вы бы лучше все же ориентировались не на устаревший проприетерный MFC, а на что-нибудь более современное, например, на тот же Qt и GNU C++ компилятор.

kontiky

Цитата:

GNU C++

А зачем свободный компилятор? Пускай лучше проприетарный - он же наверняка лучше качеством. Пример: я вот когда-то компилировал DjVu Libre под винду - так вот, gcc юниксовый у них там компилировал те исходники - а загрузил я их в MS Visual C++ 6.0 - как посыпались ошибки валом! Просто диву даешься - и как это gcc у них всё это умудрился скомпилировать.
Qt - это всё-таки, согласитесь, более как экзотика.
MFC - может, и устаревший, зато это просто и понятно всем.
Впрочем, всё равно это пока не суть дело - сначала надо понаделать консольных алгоритмов. К тому времени - через года 2 - MFC окончательно загнётся.
MFC я интересуюсь лишь в том смысле, что если, допустим, найдётся кто-то, кто будучи чайником, захочет сделать визуальное приложение, но не зная как и на чём - а тут мы ему и подскажем простейший вариант - MFC.
STL меня интересует в том плане, чтобы научиться читать чужие исходники на STL (а это, допустим, WinDjView). Для проекта же лучше не применять STL - его знают только продвинутые программисты.

Цитата:

Пускай лучше проприетарный - он же наверняка лучше качеством.

рассмешил, спасибо.

Цитата:

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

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

Добавлено:

Цитата:

STL меня интересует в том плане, чтобы научиться читать чужие исходники на STL (а это, допустим, WinDjView). Для проекта же лучше не применять STL - его знают только продвинутые программисты

СТЛ -стандарт языка, если его программист не занет, значит он не программист, или скажем программист, который 10 лет ничего не делал, что почти одно и то же сейчас.

terminat0r

Цитата:

рассмешил, спасибо.

Это высказывание мне ни о чём не говорит. Ещё раз повторяю: ИМХО Visual C++ v6.0 гораздо лучше, чем gcc++. Может быть и есть что-то лучше, чем Visual C++ v6.0, но насколько это нечто известно/популярно?

Цитата:

СТЛ -стандарт языка, если его программист не занет, значит он не программист,

Что за, извините, откровенная глупость? Подобный подход абсолютно неприемлем для данного проекта. Большинство людей - это как раз чайники, на них я и ориентируюсь. Лучше пусть 10 чайников напишут свой код на MFC, чем 1 профессионал (а на деле не будет ни одного) напишет то же самое на STL. Надо же реально смотреть на вещи. Качество образования в провинциальных ВУЗах сейчас довольно хреновое, учёба выглядит откровенной профанацией - откуда прикажете набирать "настоящих профессионалов"?

Цитата:

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

Говорите дело, пожалуйста, а не умничайте попусту.

U235

Цитата:

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

Фильтров - да, но на детектор deskew шумы не очень влияют.

Цитата:

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

Как раз подобному проекту будет нужен СТЛ как никому другому, потому что нет просто другого выхода. Если кто-то возьмется писать собственный клас динамических массивов (в замену СТЛ вектора) или воьмет какой то левый, то во первых- это уже не чайник, во вторых, читать и разбираться чайникам (почему это не работает) будет намного уже труднее.
И это не умничание а просто дружеский совет.
Поверьте, я тоже немножко знаю, что такое программирование.

Я сделал сайт на sourceforge:

http://sourceforge.net/projects/bookscanlib/

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

Добавлено:
terminat0r

Цитата:

Как раз подобному проекту будет нужен СТЛ как никому другому, потому что нет просто другого выхода.

Вот это уже дельное соображение. Просто я сам STL не знаю и для простых проектов никогда в нём нужды не испытывал. А изучать STL - на это времени пока было жалко.
Если окажется, что без STL действительно никак не обойтись - то задействуем его. Но, во-первых - будем стараться в минимальной степени его применить. А во-вторых - надо вообще вести дело так, чтобы в проекте могли принять участие люди как можно более низкой квалификации. Реальность окружающей жизни диктует свои крайне жёсткие условия.

Добавлено:
То есть предлагаю использовать STL-функции только в случае крайней нужды, при этом всегда снабжать их комментариями, разъясняющими чайнику, чего они там делают. А то, может быть, и вовсе делать самодельную обёртку на такие функции - это просто идея, не знаю, есть ли в этом смысл, уместно ли это. Будем смотреть в конкретных случаях.

monday2000

Цитата:

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

Не думаю, что у вас получиться что-то приемлемое с таком подходом. Я полностью согласен с мнением terminat0r.

Цитата:

Просто я сам STL не знаю и для простых проектов никогда в нём нужды не испытывал.

Видимо, все дело в том, что вы не профи в программировании. Но нужно учиться, что же делать.

Цитата:

ИМХО Visual C++ v6.0 гораздо лучше, чем gcc++.

Мой коллега "сионист" долго смеялся над этой фразой. И, отсмеявшись, навскидку выдал:
- в Visual C++ очень кривая поддержки темплейтов. Работают далеко не все. А часть - просто глючит. Вообще это основная претензия.
- в Visual C++ кривая кодогенерация (да, я лично с этим сталкивался в наших проектах. В сырцах есть workaround'ы и комменты)
- Еще - internal compiler errors на длинных именах классов (которые не очень длинные, на самом деле. Но из-за шаблонов получаются большие имена).
- Дикое кол-во кривых варнингов на код, который должен молча скипаться препроцессором (ибо он вообще для юникса написан). std::auto_ptr, который не имеет метода reset()
- Ну об убогости IDE не будем... Мы же о компиляторах все-таки
- а, у него еще iostream старый (не соответствует стандарту).

kontiky

Цитата:

Не думаю, что у вас получиться что-то приемлемое с таком подходом. Я полностью согласен с мнением terminat0r.

Имеете в виду, что надо обязательно использовать STL? Что Вы именно имеете в виду?

Конечно, я понимаю - STL - это прогрессивно, и удобно. Но, с другой стороны, представьте - приходит к нам чайник, он никакой не программист, знает там какие-то азы программирования, и согласен поучаствовать в проекте, чего-то там напрограммировать.
Но если мы изначально всё будем писать на STL - такие люди, конечно, ничего нам не скажут - они просто тихо и молча отойдут в сторону. Я уверен - так оно и будет.

С другой стороны, Вы оба ИМХO правы в том, что именно в такой деятельности, как написание "консольных" алгоритмов для работы с растровой графикой STL был бы практически незаменим - уменьшаются листинги программ, вся "рутина" загоняется внутрь. Кстати, а как там линуксоиды пишут такие алгоритмы?

Что Вы оба предлагаете практически? Принять STL в качестве основной платформы для разработки консольных алгоритмов? Заманчиво, что и говорить. Тогда нужно принять такие меры, чтобы чайник, прийдя к нам, смог сверхбыстро освоить STL - т.е. надо подобрать толковые учебники, пособия по STL и т.п.

Добавлено:
kontiky

Цитата:

Visual C++

А что же тогда взамен и где это нечто взять? И как быть с фактом, что исходники DjVuLibre были с явными ошибками - а значит, эти ошибки не замечались никем - т.е. свободно проходили у них там через компилятор - я думаю, юниксовый gcc++.

monday2000
По поводу GUI мой коллега еще рекомендут присмотреться к вот этой
http://www.wxwidgets.org/
библиотеке.

Цитата:

Что Вы оба предлагаете практически?

Использовать для разработки современные средства.

Цитата:

Тогда нужно принять такие меры, чтобы чайник, прийдя к нам, смог сверхбыстро освоить STL - т.е. надо подобрать толковые учебники, пособия по STL и т.п.

Например так. Хотя слово "сверхбыстро" по отношению к С++ это конечно сверхоптимистично. Сам по себе язык очень сложен.
И вы что, всерьез думаете, что чайник сможет легко освоить тот же VC++ и MFC? Я, например, очень сомневаюсь.


Добавлено:
monday2000

Цитата:

А что же тогда взамен и где это нечто взять?

http://gcc.gnu.org

Добавлено:
monday2000

Цитата:

И как быть с фактом, что исходники DjVuLibre были с явными ошибками

Простите конечно, но вы уверены, что это были ошибки gcc? Скорее это были ошибки (несоответствия стандарту) именно со стороны VC++.

kontiky

Цитата:

И вы что, всерьез думаете, что чайник сможет легко освоить тот же VC++ и MFC? Я, например, очень сомневаюсь.

Не, полные чайники тут безнадёжны. Я рассчитываю на "людей с навыками программирования"? Это кто? Есть такая прослойка. Сужу по Руборду - многие тут умеют немного програмировать, могут что-то простое наваять, а сложное - уже нет. Сколько раз такие ситуации тут возникали уже.
Второе: бывают и такие провинциальные программисты, которые, работая программистом, обходятся средней квалификацией. Наверное, в это трудно поверить, но скольких таких я лично знаю!


Добавлено:
kontiky

Цитата:

http://gcc.gnu.org

Эта штука под windows работает? STL она понимает? И нельзя ли писать исходники так, чтобы они компилировались как в Visual C++, так и в этом компиляторе? Насколько может быть сложен такой "взаимный переход"?
Дело в том, что всех ведь на заставишь сесть на какой-то один компилятор. Насколько критичны указанные Вами недостатки Visual C++? Как я понял, они сказываются в основном при работе с STL?
У Visual C++ есть то преимущество, что он широко известен/доступен - идёшь на базар, покупаешь диск, никакой головной боли - типа скачивать, разбираться, инсталлировать, (настраивать тоже надо?).
Пока с Visual C++ можно работать в принципе - я предпочитаю его - так проще. То же самое скажут ещё многие и многие - сколь бы крут ни был http://gcc.gnu.org .

Добавлено:

Цитата:

Простите конечно, но вы уверены, что это были ошибки gcc

Нет, не уверен. Просто исходники содержали синтаксические ошибки языка С++ - которые Visual C++ и обнаружил, и я сам удостоверился - да, это синтаксические ошибки. А раз эти ошибки в коде были, значит, их просто не замечали - а это, скорее всего потому, что их не замечал их юниксовый компилятор - иначе код просто бы не скомпилировался. А компилировали они, скорее всего, при помощи юниксового gcc (но не факт).

Добавлено:

Цитата:

По поводу GUI мой коллега еще рекомендут присмотреться к вот этой
http://www.wxwidgets.org/ библиотеке.

Всё, я понял, в чём дело. Одно дело - это программист, который сидит на этом деле, и от всего этого зависит его заработок. А другое дело - мы, любители (т.е. этот проект). Здесь можно и без лишней крутости обойтись.
Нет, любители, да ещё и без денежной оплаты ни за что не станут качать http://www.wxwidgets.org/ , http://gcc.gnu.org/ и т.п. - спасибо, если соизволят поставить Visual C++ и изучить STL (и то сомневаюсь в последнем).
Мой проект рассчитан на любителей, а не на профессионалов. А что, если допустим есть нечто ещё круче, чем http://www.wxwidgets.org/ , http://gcc.gnu.org/ - Вы бы и это предложили скачать/поставить?
Нереально, это поймите. Это реально только в одном случае: мы нанимаем людей за деньги, и требуем от них качества.
А когда всё на добровольно-бесплатной основе - так не получится. Остановимся лучше на Visual C++, причём даже лучше на 6, а не на 7 версии - хрен с ним, с недостатками, сейчас это не главное.
Вот когда и если библиотека будет готова - пусть тогда профессионалы берут её и переделывают на http://www.wxwidgets.org/ + http://gcc.gnu.org/ , а пока - нельзя всем переходить на http://www.wxwidgets.org/ + http://gcc.gnu.org/ , иначе всё дело загубим просто.
Смотрите - аналогичные проекты вообще пишут на юниксе и языке С (даже не С++) - и ничего, нормально! Просто юникс - это не для нас, мы-то все пиратские винды юзаем без проблем, а юникс редко кто ставит - только отдельные программисты, для работы.

Наиболее реальной пока мне кажется идея по избранию STL как основы проекта. Надо подумать.

Добавлено:
И потом - даже, если и http://www.wxwidgets.org/ + http://gcc.gnu.org/ так крут - каким это образом сделать так, чтобы все будущие участники проекта скачали и поставили себе именно эти пакеты ? А иначе ведь не будет достигнуто столь желанное единство программной платформы. Что, если завтра объявится некто, кто весьма так аргументированно покажет: "нет, http://www.wxwidgets.org/ - это фуфло, вчера вышел новый суперпакет, надо только его ставить".
А вот сказать всем: "купите на базаре диск с Visual C++ 6.0 (7-ка тоже пойдёт, там только надо будет компилить под 6-ку) и проинсталлируйте его" - вот это абсолютно реально, и всем это понятно, и просто. Так мы запросто достигнем единства программной платформы - что крайне важно.

monday2000

Цитата:

Эта штука под windows работает? STL она понимает? И нельзя ли писать исходники так, чтобы они компилировались как в Visual C++, так и в этом компиляторе?

Да. Да.
Есть стандарт. gcc его поддерживает, а MVC++ когда хочет - поддерживает, когда не хочет - нет.

Цитата:

Насколько критичны указанные Вами недостатки Visual C++? Как я понял, они сказываются в основном при работе с STL?

Не могу сказать определенно. Я уже давно не пишу на С++. Но мнению коллеги своего полностью доверяю.

Цитата:

Просто исходники содержали синтаксические ошибки языка С++ - которые Visual C++ и обнаружил

Если эти исходники собирались на gcc, то скорее всего это ошибки компилятора Visual C++. Нужно был взять порт gcc для виндов и им уже собирать.

Цитата:

Одно дело - это программист, который сидит на этом деле, и от всего этого зависит его заработок. А другое дело - мы, любители (т.е. этот проект). Здесь можно и без лишней крутости обойтись.

У вас определенно превратное представление о работе профессиональных программистов. Очень часто деньги платят именно за поддержку старого кода написанного черт знает на чем. На том же 6 вижуале. Люди мечтают использовать что-то более современное и качественное и не могут.

Цитата:

Нет, любители, да ещё и без денежной оплаты ни за что не станут

Похоже у вас и о любителях превратное представление

Добавлено:
monday2000

Цитата:

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

Чего я вас вообще уговариваю-то? Да пишите хоть на вижуал бейсике.

Цитата:

Наиболее реальной пока мне кажется идея по избранию STL как основы проекта. Надо подумать.

Вы мешаете в кучу яблоки , груши и селедку.

Попробуйте в таком порядке
1.Выберите язык программирования
Я так понимаю это уже С++, хотя это и не догма.
Если С++, то СТЛ УЖЕ там, так как это СТАНДАРТНАЯ библиотека алгоритмов, и незачем на этом зацикливаться.
2. выберете платформу и визуальную библиотеку для интерфейса
это - или Виндовс только (тогда любая- MFC, .NET, не забывайте также о DELPHI и BCB VCL)
или Виндовс + Линукс
тогда QT, wxWidgets, можно написать и на JAVA интерфейс, как это напр в Мепле и Матлабе сделано а библиотеки с алгоримами все равно скомпилировать в *.dll или *.so

3. в зависимости от п 2 выберите компиллятор.

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

Цитата:

Нет, любители, да ещё и без денежной оплаты ни за что не станут качать http://www.wxwidgets.org/ , http://gcc.gnu.org/ и т.п. - спасибо, если соизволят поставить Visual C++ и изучить STL (и то сомневаюсь в последнем). Мой проект рассчитан на любителей, а не на профессионалов. А что, если допустим есть нечто ещё круче, чем http://www.wxwidgets.org/ , http://gcc.gnu.org/ - Вы бы и это предложили скачать/поставить?

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

MFC- это библиотека микрософта которая не отличается ни удобством ни доступностью, к тому же она действительно морально устарела где-то 6-8 лет назад.
если честно, то вам не следует браться за этот проект, так как вы не компетентны, или сначала попросту подчитать о состоянии программирования в целом, чтобы не было такого, о чем говорит bolega

monday2000

Цитата:

1.Выберите язык программирования
Я так понимаю это уже С++, хотя это и не догма.

Действительно. Начните с этого.
bolega

Цитата:

5 страниц флуда и ничерта больше. Он зашел, почитал тутошний треп, плюнул, сказал что-то типа "что за глупость тут городят" и ушел.

Давайте конкретнее - в чем именно глупость?

Короче:
1. Я буду делать так, как умею - т.е. использовать Visual C++ 6.0.
2. По поводу STL: подумаю.
3. По поводу MFC: можем пока голову не ломать - вопрос о визуальном интерфейсе встанет не скоро, пока обойдёмся только консольными приложениями.