JDF – полиграфия индустриясы үшін маңызды техникалық стандарт. Жұмыс ағымын жақсартады, өндірушілер арасындағы байланысты қамтамасыз етеді. CIP4 ұйымы басқарады.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
JDF (Job Definition Format) – графикалық өнер индустриясы қолданбалар саласының жұмыс ағынын жеңілдету үшін әзірлеген техникалық стандарт. Бұл жұмыс билеттері, хабарлама сипаттамалары және хабарламалар алмасу туралы XML форматы. JDF-ті CIP4 – баспаға дейінгі, баспа және баспадан кейінгі процестерді біріктіру жөніндегі халықаралық ынтымақтастық басқарады. JDF 1999 жылы Adobe Systems, Agfa, Heidelberg және MAN Roland бастамашы болды, бірақ 2000 жылы Drupa кезінде CIP3-ке тапсырылды. CIP3 кейін CIP4 деп аталды. Бастапқыда жұмыс кестесі офсеттік және цифрлық баспа жұмысына бағытталған, бірақ веб (ролл) жұмыс жүйелеріне, газет жұмыс ағынына және қаптама және жапсырма жұмыс ағынына кеңейтілді. Оны препресс индустриясының қауымдастығы CIP4 жариялады және ол CIP3 баспа өндірісі форматының (PPF) және Adobe Systems портативті жұмыс билеті форматының (PJTF) мұрагері ретінде қарастырылады. JDF стандарты 1.7 нұсқасында. JDF-ті анықтау және жариялау процесі 1999 жыл шамасында басталды. Стандарт жетілген жағдайда және көптеген сатушылар оны іске асырды немесе іске асыру процесінде. JDF PARC, көп өнім берушілер арасындағы JDF өзара іс-қимыл қабілеттілігін көрсету, 2004 жылғы Drupa баспа өнеркәсібі көрмесінің маңызды оқиғасы болды және 21 өнім беруші жалпы қырық өнім жұбының өзара іс-қимылды көрсетуге немесе көрсетуге тырысты. JDF – кеңейтілетін формат. Ол JDF файлдарын және JMF, HTTP арқылы XML негізделген жұмыс хабарламалар форматын анықтайды. Іс жүзінде JDF-ке қосылған өнімдер бір-бірімен JDF файлдарын, әдетте «жедел папкалар» арқылы немесе желі арқылы, немесе желі арқылы JMF хабарламаларын алмасу арқылы қарым-қатынас жасай алады. Жұмыс ағыны қолданбаларына тән, JDF хабарламасында әр «торапқа» қандай файлдарды енгізу керектігін және олардың қайда орналасқанын, сондай-ақ қандай процестерді орындау керектігін анықтауға мүмкіндік беретін ақпарат бар. Содан кейін ол JDF жұмыс билетін өзгертіп, не істегенін сипаттайды және JDF билетін тексеріп, хабарды және оны қосатын файлдарды келесі қайда жіберу керектігін анықтайды. CIP4 және JDF форматының мақсаты – құрылғыны автоматтандыруды, басқару деректерін жинауды және жұмыс еденінің механикалық өндіріс процесін, тіпті буып-түю, дайын өнімдерді паллеттерге жинау сияқты нәрселерді қоса алғанда, баспа және кросс-медиа жұмысының бүкіл өмірлік циклын қамту. JDF-ті толық іске асыру үшін стандартты көбірек сатушылар қабылдауы керек. Сондықтан, JDF жүйесінің артықшылықтарын толық пайдалана алатын пайдаланушылар аз. Аяқтау, байлау және басып шығаруда автоматтандыру дәстүрі бар және JDF жүйесінің дамуын басқара алатын жеткілікті ірі компаниялар аз. Бірақ бизнес жүйелерін жасаушылар әлі де JDF-ті толықтай қолдау керек. Бұл жерде дәл осындай прогресс жасалмаған, себебі бұл компаниялардың көбісі шағын мамандандырылған компаниялар, олар мұндай дамуды басқаруға ресурстары жоқ және графикалық өндіріске маманданбаған. Сонымен қатар, саудада JDF-пен үйлесімсіз ірі өндірістік машиналар бар. Графикалық өнер бизнесі жыл сайын қысқарып келеді және кез келген ірі капитал шешімдері бұрынғы жылдардағыдан әлдеқайда тәуекелді. JDF-ті қабылдауға негізделген ынталандыру көп жағдайда иелерді қазіргі кездегі «қабылдауға болатын» машиналардан бас тартып, біршама жылдам, JDF-ке сәйкес келетін күрделі құралдарды сатып алуға итермелеу үшін жеткіліксіз. Бұл, әсіресе, талаптарға сай келмейтін өндіріс машиналарының көп мөлшерін пайдаланылған жабдықтар нарығында және аукциондық сатылымда жаңа жабдықтан бағаны едәуір төмендетіп сатумен айналысатын нарықтарда орын алады.
JDF (Job Definition Format) is a technical standard developed by the graphic arts industry to facilitate cross vendor workflow implementations of the application domain. It is an XML format about job ticket, message description, and message interchange. JDF is managed by CIP4, the International Cooperation for the Integration of Processes in Prepress, Press and Postpress Organization. JDF was initiated by Adobe Systems, Agfa, Heidelberg and MAN Roland in 1999 but handed over to CIP3 at Drupa 2000. CIP3 then renamed itself CIP4. The initial focus was on sheetfed offset and digital print workflow, but has been expanded to web(roll) fed systems, newspaper workflows and packaging and label workflows. It is promulgated by the prepress industry association CIP4, and is generally regarded as the successor to CIP3's Print Production Format (PPF) and Adobe Systems' Portable Job Ticket Format (PJTF). The JDF standard is at revision 1.7. The process of defining and promulgating JDF began circa 1999. The standard is in a fairly mature state; and a number of vendors have implemented or are in the process of implementing it. JDF PARC, a multivendor JDF interoperability demonstration, was a major event at the 2004 Drupa print industry show, and featured 21 vendors demonstrating, or attempting to demonstrate interoperability between a total of about forty pairs of products. JDF is an extensible format. It defines both JDF files and JMF, a job messaging format based on XML over HTTP. In practice, JDF enabled products can communicate with each other either by exchanging JDF files, typically via "hot folders", or the net or by exchanging JMF messages over the net. As is typical of workflow applications, the JDF message contains information that enables each "node" to determine what files it needs as input and where they are found, and what processes it should perform. It then modifies the JDF job ticket to describe what it has done, and examines the JDF ticket to determine where the message and accompanying files should be sent next. The goal of CIP4 and the JDF format is to encompass the whole life cycle of a print and cross media job, including device automation, management data collection and job floor mechanical production process, including even such things as bindery, assembly of finished products on pallets. Before JDF can be completely realized, more vendors need to accept the standard. Therefore, few users have been able to completely utilize the benefits of the JDF system. In finishing and binding, and printing there is a tradition of automation and few large enough dominating companies that can steer the development of JDF system. But it is still necessary for the manufacturers of business systems to fully support JDF. The same progress has not been made here probably because many of these companies are small specialty companies who haven't the resource to manage such development and who don't specialize on graphic production. In addition, there is a huge amount of large capital production machinery already existing in the trade which is incompatible with JDF. The graphic arts business is shrinking yearly and any large capital decision is much more a risk than in previous years. The underlying incentive to adopt JDF is not sufficient in most cases to cause owners to abandon "acceptable" machinery that they presently have in favour of a large capital purchase of somewhat faster, JDF compliant capital goods. This is especially true in markets where large amounts of non compliant production machinery are being sold in the used equipment market and auction sales at considerable reductions in price from new equipment.
JDF-те тексеру
JDF 1.1 нұсқасында сынау және жұмсақ сынау сәтті орындалуы үшін қажетті барлық параметрлерді кіріс ретінде қабылдайтын атомдық процесс ретінде анықталған. Бұл бірнеше кемшіліктерге әкелді:
In JDF 1.1, proofing and soft proofing were defined as an atomic process on which the input were all the parameters required for a successful process. This has some drawbacks:
Икемділіктің жетіспеуі: семантика нақты бір жұмыс ағынына байланысты болғандықтан, ол процестерді және кіріс ретінде қолданылатын ресурстарды анықтаумен шектелді. Бақылаудың қиындығы: бақылау үшін қажетті барлық ақпаратты қамтитын кіріс ресурстарын анықтау қиынға соқты. Дубликация: сынау және басып шығаруды анықтау үшін бірдей ақпаратты қайта-қайта пайдалану қажет болды. Егер әртүрлі ресурстар қолданылса, бұл дубликацияға алып келді. JDF 1.2 нұсқасынан бастап, сынау және жұмсақ сынау процестері жұмыс ағынын анықтауға арналған біріктірілген процесс пайдасына тоқтатылды. Жұмыс тізімі өңдеуді нақты анықтайды және оны әртүрлі жұмыс ағынында жүзеге асыруға мүмкіндік береді. Осы мақсатта, атомдық процестер әртүрлі конфигурациялар/опцияларды анықтау үшін қажетті барлық ақпаратты сақтауға қабілетті болды.
Lack of flexibility: the semantics is specific for one workflow therefore limited to the definition of the processes and the resources that it can take as input. Lack of control: it is difficult to define the input resources with all the information required for control. Duplication: similar information has to be used to define both proofing and printing. If different resources are used, this will result in duplication. From JDF 1.2 proofing and soft proofing were deprecated in behalf of a combined process to specify the proofing workflow. The job ticket explicitly defines the processing and provides the flexibility to implement them in different workflows. In order to do that, the atomic processes were made capable of keeping all the information necessary to specify different configurations/options.
Профильдеудің біріктірілген процестері
Проверкалауды процестердің бірегей комбинациясымен сипаттау мүмкін емес, бұл өз кезегінде RIP-тің (растрлік бейне процессоры), проверкалауға қолданылатын құрылғылар және проверкалау өндірістік жұмыс ағынының мүмкіндіктеріне байланысты болады. Дегенмен, проверкалау үшін жалпы біріктірілген процесті анықтау мүмкін. Бұл процестің жұмыс ағынындағы қадамын сипаттауға мүмкіндік береді. Жалпы біріктірілген проверкалау процесі келесі JDF процестерін біріктіреді:
It is impossible to describe proofing by a unique combination of processes which in turn will depend on the capabilities of the RIPs (Raster image processor), the devices used for proofing and the proofing production workflow. It is still possible to define a generic combined process for the proofing. This will allow it to describe its step in a workflow. The generic combined proofing process combines the following JDF processes:
ColorSpaceConversion (1): кіріс RunList мазмұнын кіріс түстер кеңістіктерінен баспа машинасының түстер үлгісіне түрлендіреді. Түсіндіру: кіріс RunList файлының (немесе файлдарының) мазмұнын түсіндіріп, рендерингтен өткізу үшін ішкі дисплей тізіміне түрлендіреді. Рендеринг: растрлық деректерді көрсету. Скрининг: растрлық деректерді скринингтеу. ColorSpaceConversion (2): деректерді баспа машинасының түстер үлгісінен профер құрылғысының түстер үлгісіне түрлендіреді. Жапсыру: егер жапсыруды тексеру орындалса, жапсырылған парақтардағы беттер мен белгілерді біріктіреді. ImageSetting: дәлелдеменің нақты басылуын анықтайды. Проверкалау құрылғысының ерекшеліктеріне байланысты DigitalPrinting де қолданылуы мүмкін. Реттелу толығымен қатаң емес (әртүрлі қадамдардың реттілігімен бірдей нәтижеге қол жеткізуге болады), бірақ кейбір басымдық ережелері бар: бірінші түстер кеңістігін түрлендіру екіншісінен бұрын орындалуы керек, рендеринг түсіндіруден кейін орындалуы керек, скрининг рендерингтен және екінші түстер түрлендіруден кейін орындалуы керек, ал ImageSetting/DigitalPrinting скринингтен кейін орындалуы керек.
ColorSpaceConversion (1): converts the contents of the input RunList from the input color spaces to the color model of the press. Interpreting: interprets the input RunList file(s) and converts them to an internal display list in order to go through the Rendering. Rendering: renders the raster data. Screening: screens the raster data. ColorSpaceConversion (2): converts the data from the press color model to the proofer device color model. Imposition: if imposition proofing is done, combines the pages and marks on the imposed sheets. ImageSetting: specifies the actual printing of the proof. Depending on the characteristics of the proofing device DigitalPrinting can be used as well. The ordering is not completely strict (same result may be achieved with different order combination of steps), but there are some precedence rules: the first color space conversion must be done before the second one, rendering must be done after interpreting, screening in turn must be done after rendering and the second color conversion, ImageSetting/DigitalPrinting must be done after screening.
Жұмсақ қорғауға арналған біріктірілген процестер
Профильдеумен салыстырғанда, баспаға арналған сынақ дайындалмағандықтан, ImageSetting / DigitalProofing процестері қажет емес. Сонымен қатар, дайындалған деректер тікелей мақұлдау процесіне жіберіледі, ол деректерді дисплейде көрсетуге, сынақты мақұлдауға/қабылдамауға және қажет болған жағдайда цифрлық қолтаңбамен түсіндірмелер қосуға мүмкіндік беретін пайдаланушы интерфейсін қамтамасыз етуі керек. Барлық тапсырыс шарттары бұрынғысынша күшінде.
Compared to proofing, since no printed proof is produced, no ImageSetting/DigitalProofing processes are required. Moreover, the rendered data is sent directly to the Approval process that must implement a user interface to show those data on the display and allow him/her to approve/reject the proof and eventually annotate it using digital signature. All the ordering consideration are still valid.
Түс кеңістігі
Профильдеумен өндіріс жұмыс ағынында кіріс активтерінің түс кеңістіктері пресс түс кеңістігіне, ал пресс түс кеңістігі профер түс кеңістігіне түрлендірілуі керек. Сондықтан JDF-де екі түрлі ColorSpaceConversion процесі қажет, және нақты жұмыс ағынына және құрылғылардың мүмкіндіктеріне байланысты, оларды бір біріктірілген процеске біріктіруге болады.
In a production workflow with proofing, there must be both the conversion of the input asset color spaces to the press color space and the one of press color space to the proofer color space. So in JDF two different ColorSpaceConversion processes are required and depending on the exact workflow and on the capabilities of the devices, they can be included in the same combined process.
Аударма және аударма
Дәлелдеудің біріктірілген процесіне енгізілетін деректер көбінесе түсіндіруді (JDF ByteMap-тан басқа) және көрсетуді талап ететін. Ондай жағдайларда олар дәлелдеу қадамын сипаттайтын біріктірілген процеске қосылады.
Input data to the proofing combined process usually required both interpreting (with the exception of JDF ByteMap) and rendering. In these cases they will be included in the combined process describing the proofing step.
Сурет орнату/цифрлық басып шығару
Дәлелді басып шығару үшін, дәлелді біріктірілген процестің соңында ImageSetting/DigitalPrinting процесін көрсету қажет, осылайша дәлелдің қалай басылатыны нақтыланады.
For printing the proof ImageSetting/DigitalPrinting process has to be specified at the end of the proofing combined process in order to define how the proof is actually printed.
Бекіту
Соңғы өндірістік басылымды бастау алдында орындалуы керек.
Must be executed before the final production printing can be started.
HP мысалы: сынақ уақытын қысқарту
HP өзінің сынақ өнімдеріне JDF технологиясын енгізеді. Бұл толық процестің бір қадамы болғанымен, JDF басып шығару процесінің уақытын қысқартып, принтерлерді тиімдірек етеді, себебі дәстүрлі түрде сынақтарды жасау және жеткізуге бірнеше күн кетіп жатады. HP PDF файлдарын қашықтан сынаққа жібереді. JDF файлы клиентке жұмыс туралы ақпаратты (түс профильдері, жұмыс тапсырмасының толық мәліметтері) қосуға мүмкіндік береді. Алдағы уақытта сынақтарға түзетулер енгізу және бекіту үшін цифрлық қолтаңбалар қолданылатын болады.
HP incorporates JDF into its proofing products. Even if it's only one step in the total process JDF cuts time from the printing process making printers more efficient because proofing traditional generation and delivery of proofs can take days. HP sends PDF files to a remote proofing. JDF file enables the inclusion of job information (color profiles, job ticket details ) that is sent to the client. In the future marking up the proof and digital signatures for approval will be implemented.