Крутой креатифф в илле

[Zest]

Ответ: Крутой креатифф в илле

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

Еще раз: файловая система это база данных. Более того, фактически любой файл, кроме потоковых видео и аудио - либо является базой данных, либо может быть обработан как запись базы данных. Я уж не говорю о графических файлах, которые сугубо организованы как базы данных.

Когда вы пишите "OPI это" и затем рассказываете о том же самом о чем я написал - то о чем думаете? О матах которые нельзя говорить?

 

[Zest]

Ответ: Крутой креатифф в илле

Смешно слышать о том, что файловая система не является базой данных, зная как как расшифровывается аббревиатура FAT: File Allocation Table. Или, NTFS, на запрос по которой Lingvo благосклонно разъясняет:

[New Technology file system] файловая система новой технологии; файловая система Windows NT (файловая система, обладающая возможностями восстановления, использующая парадигмы базы данных, обработки транзакций и объектов для того, чтобы обеспечить защиту данных и надежность файловой системы; поддерживает объектно-ориентированные приложения, представляя все файлы как объекты, обладающие атрибутами, определяемыми пользователями системы) Конец цитаты.

 

[JAW]

Ответ: Крутой креатифф в илле

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

т.е. OPI предполагает подключение линков на этапе растеризации.
Современные системы - на этапе записи выходного файла.

Файловые системы и базы данных...
База данных (реляционная) является набором индексированных таблиц объединённых отношениями и связями.

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

Принципиально разная реализация.

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

 

[djtape]

Ответ: Крутой креатифф в илле

Холивар на новом уровне?

 

[lunatik]

Ответ: Крутой креатифф в илле

Напомню что мне плевать на обе - обе полное авно.

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

 

[Zest]

Ответ: Крутой креатифф в илле

Я читал про эту ОПЮ еще когда у меня, кажется, и компа не было. Когда появился, снова читал (как Мицгол, буквально) и возрадовался тому, что на 256-м проце с 4-мя метрами памяти и тормозным винтом оказывается можно запросто заверстать журнальчег! Потому что загружается картинка экранного разрешения, а связанная с ней печатного - просто лежит на диске и используется только при печати. Это вы и называете позднее связывание? Хорошо. Какая собственно разница относительно идеи связывания файлов в документ по типу веб-пар - о "позднем" связывании идет речь, или о "раннем"? Системе управления фиолетово что там раньше, что позже - главное чтобы пачка файлов оставалась пачкой файлов, а не терялась в бескрайних просторах локальных сетей. Чтобы можно было раскрутить связи взявшись за ЛЮБОЙ файл.

Файловые системы и базы данных...
База данных (реляционная) является набором индексированных таблиц объединённых отношениями и связями.

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

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

Реляционная база данных это более одной таблиц организованных в виде столбцов каждый определенного типа данных, данные которых хранятся в строках. Если есть две или более таблиц - между ними возможны отношения - реляции. Разумеется их можно сразу предопределить в самой базе, а можно это делать в структуре запросов. Это, уже, не принципиально. Принципиально что один факт в базе данных имеет ровно одну запись.

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

Давайте представим что Проводник имеет интерпрентатор SQL-запросов и я ему пишу: SELECT * FROM C:\ WHERE Size >= 1000 AND Created BETWEEN #09.11.2003# AND #06.04.2006# И я получу таблицу, то есть список файлов со всеми их атрибутами, включая размер файла и дату создания. Я могу скопировать этот список в буфер или сохранить условия поиска на диск (*.fnd) А главное что я могу взять и скопировать все найденные файлы в отдельную папку, то есть получить новую таблицу для следующих запросов.

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

 

[Zest]

Ответ: Крутой креатифф в илле

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

Вы сначала признайте что рубрика посвященная Люстре выглядит как место зараженое радиацией. Одни желтые знаки "Опасность" кругом.

 

[Zest]

Ответ: Крутой креатифф в илле

Например метаданные. Адоба вдалбливает метаданные в графические файлы, Майкрософт туда же, например вы легко можете вкатать слова песни в ее МР3 файл. Но поскольку записи файловой системы это сами файлы, то рыскать среди их метаданных - дело гиблое. Адоба их индексирует, Майкрософт тоже - это же все известно. Но если бы обеспечить связи между файлами так, чтобы 10 файлов таскались друг за другом - метаданные можно было бы хранить в отдельном файле. Например можно было бы связать файлы одного альбома (одной фотосессии) не через членство в папке, а через связь с файлом метаданных.

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

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

 

[JAW]

Ответ: Крутой креатифф в илле

что на 256-м проце с 4-мя метрами памяти и тормозным винтом оказывается можно запросто заверстать журнальчег!

Я на XT верстал с 640 кило памяти... А некоторые умудрялись и на PDP-8
идея OPI заключается в том, что у тебя где-то там стоит офигенно мощный RIP. Ты пишешь PostScript в котором у тебя LowRes изображения и ссылки на HiRes, т.е. уже в PostScript. Такой подход может приносить массу ошибок.
А "раннее связывание", это когда на этапе записи PostScript у тебя уже в нём оказывается HiRes. При этом, естественно, при вёрстке ты работаешь с изображением в низком разрешении.

С какого это хрена связи должны быть в самой базе чтобы ей считаться реляционной?

База данных ценна именно этими связями и отношениями.
Без них, это мешок таблиц, не более, которые нельзя называть "базой данных". Где это хранится? Это таки храница в реляционой базе.
Первично в виде таблиц и полей связи. Вторично вне базы в виде запросов реализующих связи.

Почему используют реляционные базы и практически забыли сетевые и прочие... А потому, что существует математика, Реляционная алгебра, которая позволяет разрабатывать грамотные и правильные базы.

Файловая система... На примере FAT.
Существует физическая система, диск, который разбит на сектра.
Сектор, это физическая велична.
Сектора объединятся в кластеры (по причине малого размера таблицы FAT). Это минимальная адресуемая величина.
FAT представляет из себя таблицу в которой каждое 16 битное поле (Fat16), или 32 битное (FAT32) ссылается а номер следующего кластера в цепочке, либо имеет состояния, "пустой кластер", "конец файла", "плохой кластер".

Кроме того существует массив 256 байтных полей, который называется дирректорий содержащий имя файла, ряд атрибутов, ссылку на первый кластер, длинну файла.

Подкаталог, это файл, содержащий точно такую же таблицу, но имеющий определённый тип.

Где в этом аналогии с базой данных?

Понимаешь... Я в данном случае знаю о чём говорю.
А вот ты не знаешь и филосовствуешь.
А я философов воспринимаю только в распятом виде.

 

[Zest]

Ответ: Крутой креатифф в илле

идея OPI заключается в том, что у тебя где-то там стоит офигенно мощный RIP. Ты пишешь PostScript в котором у тебя LowRes изображения и ссылки на HiRes, т.е. уже в PostScript. Такой подход может приносить массу ошибок.
А "раннее связывание", это когда на этапе записи PostScript у тебя уже в нём оказывается HiRes. При этом, естественно, при вёрстке ты работаешь с изображением в низком разрешении.

Не заметил никакой разницы, хотя должен признать, что вообще ничего не понял в этом абзаце.

Что значит "пишешь постскрипт" и при чем тут мощный пост-скрипт принтер? Он чтоли помогает записывать постскрипт или что?

 

[Zest]

Ответ: Крутой креатифф в илле

База данных ценна именно этими связями и отношениями.
Без них, это мешок таблиц, не более, которые нельзя называть "базой данных". Где это хранится? Это таки храница в реляционой базе.
Первично в виде таблиц и полей связи. Вторично вне базы в виде запросов реализующих связи.

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

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

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

Где в этом аналогии с базой данных?

Вы же только что описали типичную реляционную БД - несколько связанных, иерархических таблиц и все равно файловая система это не БД? Но тут уже дело не в этом, а вот в чем:

А потому, что существует математика, Реляционная алгебра, которая позволяет разрабатывать грамотные и правильные базы.

ЩИТО? То есть моя рабочая база созданная без участия реляционной алгебры, поскольку каким боком алгебра может лежать к тоннам данным по проектам, заказчикам, названиям, исполнителям заказа, стоимости и тыр и пыр - ума не найду понять - неграмотная и неправильная?

Но хотя и не понял, но сразу почувствовал неколебимую нашу веру в Великую Науку! Реляционная база должна быть разработана с помощью реляционной алгебры, на меньшее мы не согласны! А лазерный принтер должен быть мощнее настольного компа, хотя непонятно откуда возьмется более мощный процессор для принтера, если его нет для компа?

 

[JAW]

Ответ: Крутой креатифф в илле

Что значит "пишешь постскрипт" и при чем тут мощный пост-скрипт принтер? Он чтоли помогает записывать постскрипт или что?

Он именно помогает записывать PostScript.
т.е. записанный на хилом верстальном компьютере PostScript мааленький такой, карманный...
А потом на монстровом RIP'е вместо превьюшек вживляются реальные изображения с большим разрешением.

Знаешь, это одна из прочих мёртво рождёных технологий.
Времён, когда компьюеры были ужастно дорогими. Когда на RIP ставили специализированные машины и т.п. Такие технологии, а в их ряду и OPI и InRIP цветоделение и даже InRIP трэппинг возможно применять только при весьма узкой клиентской базе, когда клиенты полностью работаю под требования репроцентра, или типографии.
В простейшем случае, это журнальное издательство с полностью своей полиграфической инфроструктурой (издательству принадлежит и вывод и печатные машины и технология строится в целом для всей системы).

В реальности я не разу не видел работающего OPI или InRIP цветоделения. Это такой же маркетинговый бред, как и современные системы управления производством типа Prinancy.

 

[JAW]

Ответ: Крутой креатифф в илле

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

Связать кучу таблиц можно вообще по любому полю и полям.

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

1) Да, написал. Более того, изучал теорию баз данных и реляционную алгебру.
2) Заметно, что кроме кошмарного количества таблиц не видели, а никогда не задумывались, пчему их такое кошмарное количество? Ведь практически все данные можно засунуть в одну таблицу...
3) Нельзя. Вернее можно, в принципе... Но как это будет работать...
Существуют ключевые поля, первичный ключ и вторичные поля.
Они индексируются, т.е. стоится двоичный индекс (бинарное дерево) облегчающий поиск по ним.
Первичный ключь обязан быть уникальным. Попытка добавить неуникальные данные в поле являющееся первичным ключом вызывает ошибку.

Вот ТОЛЬКО по первичным ключам и возможна связь между таблицами.
Вторичные ключи просто облегчают поиск.

Связь может быть типов:
Один-один
Один-много
много-один
Много-много.
При связи один-один возможна связь внутри таблицы.
При других типах связи требуется промежуточная таблица.

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

 

[JAW]

Ответ: Крутой креатифф в илле

Приведу тривиальный, классический пример...

В одной фирме работали Вася Пупкин и Моня Пупкина. Проживали они вместе, т.к. были мужем и женой.

В базе сотрудников, в одной таблице были поля:
Фамилия, Имя, Адрес, Телефон.

В один прекрасный момент Вася Пупкин сообщил, что телефон сменился.
Его исправили в базе.
Однако у Мони Пупкиной при этом телефон не изменился, хотя она проживает по тому же адресу.
Эта ситуация называется коллизией. т.е. неоднозначность данных.

Почему?
А потому, что при проектировании базы была допущена ошибка.
Данная таблица должна была быть разделена на две (этот процесс называется декомпозицией и его правила определены теоией баз данных).
Личность и Проживание.
Между ними должна была быть связь 1-n, или n-1, или n-n
Я бы предпочёл n-n и построил таблицу связи.

 

[ch_alex]

Ответ: Крутой креатифф в илле

В реальности я не разу не видел работающего *** или InRIP цветоделения.

Будешь в Киеве - заходи, продемонстрирую. Или я тогда неправильно понимаю термин InRIP separation.

 

[JAW]

Ответ: Крутой креатифф в илле

Будешь в Киеве - заходи, продемонстрирую. Или я тогда неправильно понимаю термин InRIP separation.

Правильно. Но это работает только как защитная мера.
Реально цветоделение по профлям для всего издания осуществлять неправильно и стороить процесс в расчёте на InRIP тже не верно.

Кстати про InRip треппинг вопрос очень сложный. IMHO он приемлим при условиях котроллируемости процесса.

 

[ch_alex]

Ответ: Крутой креатифф в илле

Я о профилях ничего не говорил. IMHO ин-рип и профили вообще разными местами относятся к растрированию на РИПе.

 

[lunatik]

Ответ: Крутой креатифф в илле

Реанимация темы. На свой страх и риск отправил этим идиотам (если кто-то еще помнит с чего началось) письмо и техтребования.

Проектная декларация.

И техтребования для дизайнера. Если есть возможность передайте их дизайнеру вашего макета.

Так, вкратце: желательно чтоб в макете не было RGB цветов (все в СМУК), а черный текст СМУК 0,0,0,100 (а не какой-нибудь 87,79,78,82 тоже с виду черный) Это базовые требования к макетам в полиграфии. Странно что он/она этого не знают. Текст ессно должен быть в кривых. Подлинкованые картинки прилагаться.

Соблюдение этих требований позволит избежать проблем при конвертации цветов и потери шрифтов при передаче макетов. Конечно мы можем сами перевести цвета в СМУК... (не факт конечно что они совпадут с теми что вы видите на своем мониторе). Но отсутствие шрифтов или линкованых картинок мы исправить не сможем.

Нет нужды передавать файл во всех возможных форматах Достаточно правильно подготовить cdr или записать правильный PDF.

Вскоре был вызван на ковер:
- Что ты себе позволяешь!!!! Они чуть не со слезами на глазах мне звонили!!!!!! Ты оскорбил их до глубины души!!!! Они сказали что в вашей компании работают грубияны!!!!

Я поинтересовался - в чем собсно грубость? Какая конкретно фраза их оскорбила?

Оказывается фраза

Это базовые требования к макетам в полиграфии. Странно что он/она этого не знают.

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

Если кому интересно могу выложить исходник в илле. 15 мб где-то в архиве. Есть еще в кореле и шопе но это уже негуманно.

http://ifolder.ru/6627171 новый макет. Что линки должны прилагаться до них доперло. Остальное, увы.

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

Эти люди настаивают на точном воспроизведении их логотипа. Цвет задан пантоном. Есть распечатка с принтера. Беда в том что пантон не совпадает с принтерной распечаткой а они его настойчиво пихают. Pantone 356M у них.

 

[djtape]

Ответ: Крутой креатифф в илле

Для начала - пантон длля какого вида печати и на какой бумаге?
Для продолжения - как же они все уже илабеаз!
Средство моего друга - merge to *.tif /350-450 dpi CMYK и ниипаццо
Использовал в типо глянцевом белорусском жуурнале - проканало.
Никто не заметил. Это правда, если очень "правильные" дизы профилей не понавтыкают.

 

[lunatik]

Ответ: Крутой креатифф в илле

Дык это... сначала хотел поковыряццо подогнать пантон->CMYK чтоб в нашей типографии на нашей бумаге выходило нечто похожее на их распечатку (там он еще и в градиенты напихан)
Потом позвонила типография - ну чё типа где пленки (мы итак их задержали из-за этих креативщиков) я плюнул, перекрасил черный текст, шрифт букварный заменил ариалом (благо похож) и загнал все в ПДФ (с конвертом в смик) Будет время - разберусь Беда что у них теперь два макета и меняют каждую неделю (во креатиф попер) Задолбаешься до ума-то доводить.