Журналы как правило требуют текст без форматирования, без стилей и с ручными ссылками, т.к. если скомбинировать в одном документе файлы из нескольких Вордов, то гарантированно или он свои ссылки забудет или стили перепутаются. Проблемы с Вордом начинаются гораздо раньше чем через 100 рисунков/таблиц/формул.
Физики и математики как правило принимают статьи в LaTeX даже в РФ. С техническими науками ситуация печальная. Например «Труды МГТУ им.Н.Э. Баумана» раньше игнорировали LaTeX, а теперь видимо узнали о существовании LaTeX и заявили на своём сайте, что его не принимают. Зато они требуют рисунки в Visio.
Да, это можно сделать завернув окружение tikzpicture в класс standalone. Класс документа standalone автоматически подгоняет размер листа под содержимое, и можно с помощью LaTeX генерить PDF с автоподбираемым размером листа. Использовать его можно так:
TikZ обеспечивает максимально нативный вид схемы. Можно нарисовать схемы с формулами LaTeX. Можно объединять их с уже существующей графикой TikZ, чтобы нарисовать схемы установок, которые не являются чисто электрическими схемами. Ни шрифты, ни типы линий ничем не отличаются от остального документа. И весь документ автоматически можно пересобрать один раз нажав на кнопку PDFLaTeX в Kile.
Похожие результаты можно получить используя экспорт SVG в PDF+LaTeX. Он подставляет шрифты LaTeX и обрабатывает формулы LaTeX. Подробнее здесь mydebianblog.blogspot.ru/2013/05/latex-inkscape.html. Но способ уже требует объединения при помощи Makefile или каждый раз переэкспортировать SVG.
Ну и если шрифты LaTeX и формулы в схемах не нужны или не важны, то можно напрямую их заэкспортировать из например KiCAD. Список свободного ПО для рисования схем есть здесь en.wikipedia.org/wiki/Wikipedia:WikiProject_Electronics/Programs
С графиками в TikZ я проблем не вижу. Чтобы строить их не всегда нужно вручную писать код TikZ. Gnuplot и Octave умеют автоматически генерить TikZ, который вставляется через /input{}.
Для Gnuplot нужно использовать set terminal tikz, а для Octave print -dtikz. При этом тоже на графике можно разместить например формулу TikZ, если заключить её в $...$. И всё тоже можно объединить через скрипты. Я так делал, чтобы автоматически перестраивать графики в отчёте, если изменились данные, пришедшие с приборов.
Вручную имеет смысл строить через TikZ графики, которые выражаются аналитической функцией. Кода здесь немного (не больше чем в Gnuplot) и результат весьма достойный.
У нас в вузе то же самое. На компьютерных специальностях, не изучив даже Pascal, студенты сразу учат С#. C# даже пытаются затаскивать на радиоэлектронные специальности, при этом обычный С и Assembler, которые нужны электронщикам для программирования микроконтроллеров, выпадают. Сейчас, правда С# у электронщиков убрали.
Не совсем с вами согласен. .NET и Mono может быть и сольются, но польза от этого слияния будет только для серверных применений, т.к. WPF и WinForms по-видимому прикручено намертво к WinAPI и перенести его куда либо невозможно. По той же причине и перенести VisualStudio куда-либо вне Windows невозможно.
И для обучения кроссплатформенному программированию всё равно С# будет использовать затруднительно, т.к. VS и WinForms не работают вне Win. Так что открытие кода .NET ничего не даст в плане продвижения open-source в вузы.
Испольузю Gnuplot с выводом результата в TikZ для пострения сложных графиков, основанных на экспериментальных данных, и непосредсвенно TikZ для построения простых графиков.
Как-то раз нужно было постоянно перестраивать графики, если добавились новые файлы данных. Решил эту задачу скриптом на баше, который смотрел есть ли новые файлы с данными и генерировал скрипт Gnuplot, который в свою очередь генерировал TikZ, которые подставлялись в отчёт.
CMake под Windows должен собирать. Возможно связано что-то с этими багами github.com/Qucs/qucs/issues/171. Подробнее не подскажу, т.к. Windows у меня нет.
Переход на Qt5 планируется примерно через год. До конца года мы должны закончить портирование на Qt4 (сейчас собирается через Qt3Support )
В qucsconv могли не добавить поддержку BSIM. Нужно будет посмотреть исходник на этот счёт.
Относительно совместимости нетлиста здесь нужно читать работы основателей проекта, чем они мотивировали разработку своего собственного формата. Согласен, что идея была не очень хорошая. Все остальные свободные симуляторы имеют SPICE-совместимый нетлист. Мы сейчас работает над тем, чтобы подключать к Qucs spice-совместимые симуляторы (ожидается примерно через релиз). В том числе будет компонент, который будет передавать ядру пользовательские spice-параметры.
Файл не совсем обычный. Нужно вырезать из него то что относится к модели транзистора ( .MODEL и то что идёт за ним ) и сохранить отдельно как библиотеку spice, затем при помощи qucsconv сконвертировать её в библиотеку Qucs. Оттуда можно вставить транзистор.
BSIM4 модели есть. Они находятся в группе Компоненты->Устройства Verilog. Что понимается под файлом «SPICE от фабрики». Если есть библиотека SPICE, то её можно сконвертировать в библиотеку Qucs при помощи утилиты qucsconv.
KiCAD не имеет встроенных средств визуализации результатов моделирования, а у Ngspice — графический интерфейс для этих целей очень и очень примитивен.
Я считаю, что объединять симулятор и разводчик ПП в одну программу не следует. Иначе получится монстр наподобие Multisim, который ни для того ни для другого не годится.
Несмотря на внешнее сходство Qucs и gEDA выполняют разные задачи. При помощи gEDA разрабатывают печатную плату, схему она смоделировать не может. А Qucs — это моделировщик электронных схем, для разработки печатной платы он не предназначен. Сравнивать их сложно. Единственная похожая функция — это только то, что из gEDA можно заэкспортировать spice-netlist и смоделировать его в Ngspice.
Здесь border задаёт поля.
Похожие результаты можно получить используя экспорт SVG в PDF+LaTeX. Он подставляет шрифты LaTeX и обрабатывает формулы LaTeX. Подробнее здесь mydebianblog.blogspot.ru/2013/05/latex-inkscape.html. Но способ уже требует объединения при помощи Makefile или каждый раз переэкспортировать SVG.
Ну и если шрифты LaTeX и формулы в схемах не нужны или не важны, то можно напрямую их заэкспортировать из например KiCAD. Список свободного ПО для рисования схем есть здесь en.wikipedia.org/wiki/Wikipedia:WikiProject_Electronics/Programs
С графиками в TikZ я проблем не вижу. Чтобы строить их не всегда нужно вручную писать код TikZ. Gnuplot и Octave умеют автоматически генерить TikZ, который вставляется через /input{}.
Для Gnuplot нужно использовать set terminal tikz, а для Octave print -dtikz. При этом тоже на графике можно разместить например формулу TikZ, если заключить её в $...$. И всё тоже можно объединить через скрипты. Я так делал, чтобы автоматически перестраивать графики в отчёте, если изменились данные, пришедшие с приборов.
Вручную имеет смысл строить через TikZ графики, которые выражаются аналитической функцией. Кода здесь немного (не больше чем в Gnuplot) и результат весьма достойный.
Например:
Здесь достаточно замороченный график с греческими буквами и точками пересечений на кривой.
И для обучения кроссплатформенному программированию всё равно С# будет использовать затруднительно, т.к. VS и WinForms не работают вне Win. Так что открытие кода .NET ничего не даст в плане продвижения open-source в вузы.
Например простой график выглядит так:
Как-то раз нужно было постоянно перестраивать графики, если добавились новые файлы данных. Решил эту задачу скриптом на баше, который смотрел есть ли новые файлы с данными и генерировал скрипт Gnuplot, который в свою очередь генерировал TikZ, которые подставлялись в отчёт.
Сейчас над проектом работают не менее 6 человек. В основном специалисты по GUI. Собственно ядром моделирования занимаются 2 человека.
github.com/Qucs/qucs/issues/181
github.com/Qucs/qucs/issues/77
Пока работают только базовые симуляции и очень мало компонентов.
Есть нестабильная ветка github.com/ra3xdh/qucs/tree/spice4qucs. Требуется пересобрать только GUI. Использовать на свой страх и риск.
Переход на Qt5 планируется примерно через год. До конца года мы должны закончить портирование на Qt4 (сейчас собирается через Qt3Support )
Относительно совместимости нетлиста здесь нужно читать работы основателей проекта, чем они мотивировали разработку своего собственного формата. Согласен, что идея была не очень хорошая. Все остальные свободные симуляторы имеют SPICE-совместимый нетлист. Мы сейчас работает над тем, чтобы подключать к Qucs spice-совместимые симуляторы (ожидается примерно через релиз). В том числе будет компонент, который будет передавать ядру пользовательские spice-параметры.
Я считаю, что объединять симулятор и разводчик ПП в одну программу не следует. Иначе получится монстр наподобие Multisim, который ни для того ни для другого не годится.
Для цифровых схем есть файловый компонент «Устройство Verilog». Ему надо дать исходный текст Verilog и он создаёт нужный компонент.
Для аналоговых схем можно вкомпилировать компонент Verilog прямо в Qucs при помщи генератора моделей ADMS. Для этого есть руководство здесь