¿Es posible utilizar un flujo de trabajo de código completamente abierto para el diseño de impresión?

¿Es posible usar solo herramientas de código abierto para producir obras de arte de nivel profesional? ¿Alguien lo ha hecho realmente? Si no, ¿dónde están las brechas actuales?

Supongamos que estoy produciendo un pequeño folleto de varias páginas que incluye fotos, dibujos lineales y CMYK + un color directo, y necesito llevarlo a un PDF que pueda entregar a las imprentas.

Ahora he agregado una recompensa para alentar respuestas adicionales.

Respuestas (1)

Un poco de superposición con mi respuesta aquí , y puede obtener direcciones URL desde allí, pero sí, un flujo de trabajo de Gimp/Inkscape/Scribus podría estar bien.

¿Realmente lo hiciste? Sí. De hecho, trabajo con herramientas en su mayoría gratuitas y de código abierto sin quejas.

En mi experiencia, a menudo tiene que usar mucho su cerebro y crear sus propios trucos para lograr ciertos requisitos exigidos por la industria cuando la herramienta de código abierto aún no ha recibido alguna característica. Por ello, el factor tiempo es clave para decidir. Si lo que se necesita es un entorno muy rápido y estresante, sin problemas de flujo de trabajo, muy exigente en funciones (a menudo es el trabajo típico de un artista gráfico), en mi opinión, solo la mejor de las mejores herramientas comerciales lo mantendría totalmente seguro. Aun así, prefiero los flujos de trabajo de código abierto.

Buen material. Cuando hablas de solucionar las funciones que faltan, ¿algún ejemplo?
UE. Sería muy largo responder (no digo que su pregunta sea vaga ...) porque me refería como lo hizo él, a la mayoría de las herramientas de código abierto para este asunto. Bueno, si quieren algunos ejemplos, solo el hecho de que Inkscape aún no tiene un soporte adecuado de CMYK, ni (al menos en Windows) un soporte completo en Gimp, eso lo convierte en un obstáculo para muchas situaciones. Aún así, puedes hacer cosas (oh, por cierto, olvidé el importante sk1, terrible memoria, acabo de actualizar el otro hilo) con trucos y todo.
Supongo que otra es que los colores directos normalmente se especifican como referencias de Pantone, que tienen derechos de autor y, por lo tanto, no estarán disponibles como bibliotecas en ningún software de código abierto.
Yo también he estado jugando con el flujo de trabajo de Scribus+Inkscape+Gimp. Ciertamente es factible. Es posible que deba transmitir problemas de preimpresión, como el reventado, al lado de la impresora a través del flujo de trabajo de PDF. CMYK no debería ser un gran obstáculo. Eso es algo que el RIP de preimpresión debería poder manejar. Sin embargo, la omisión de colores directos sería un poco más difícil de manejar en el lado de la preimpresión.
Entonces, ¿cómo funciona la economía de FOSS frente a la comercial para ahorrar dinero? Los costos de Adobe y Quark son legendarios en la industria, pero no es como si tuviéramos que pagarlos cada vez que producimos un trabajo. Si las herramientas FOSS no son compatibles con tecnologías tan fundamentales para la impresión como CMYK y Pantone, entonces diría que los costos de soporte asociados con las herramientas FOSS son tanto como las licencias comerciales.
@philip... eso es ciertamente cierto. Desde una perspectiva puramente de costos, es una cuestión de escala. Si una persona hace 20 horas de trabajo independiente al año, probablemente no sea rentable invertir unos cuantos mil dólares en la suite de Adobe. Pero de lo contrario, sí, es probable que sea más barato optar por la plataforma 'estándar' madura de Adobe. Mucha gente, sin embargo, mira más a FOSS desde un punto de vista puramente político.
En realidad... este podría ser un gran nicho para una impresora de calidad... centrarse en manejar el trabajo producido a través de un flujo de trabajo del sistema operativo.
Entiendo todo el debate de FOSS, pero cuando intentamos administrar un negocio, realmente se convierte en una cuestión de cuánto vale nuestro tiempo. Muchos de los proyectos FOSS más exitosos que he visto y usado han encontrado una manera de monetizar su trabajo de una forma u otra, generalmente a través de contratos de soporte para ayudar a los usuarios a ponerse al día. Me parece que Scribus necesita llenar algunos vacíos bastante grandes en la funcionalidad antes de que realmente pueda competir con su competencia comercial antes de que tenga algún impacto en el mercado. Personalmente, creo que el mercado necesita una buena patada en los pantalones, así que estoy totalmente de acuerdo.
Desde la perspectiva de una película o placa, los problemas de punto/CMYK se debilitan. Antes de todas estas excelentes funciones de color, los diseñadores se dieron cuenta de que, para la tinta, cada placa es independiente del color. Rutinariamente diseñamos en blanco y negro y luego volvimos a etiquetar la película. Exportamos capas de colores directos de Photoshop, las aplanamos y las imprimimos en escala de grises y luego le indicamos a la impresora qué color Pantone usar para esa placa. A menudo, agregamos nombres de color manualmente entre las marcas de recorte. Nunca he encontrado que el color plano sea un gran problema sin importar las herramientas.
CMYK de archivos RGB podía ser complicado en los viejos tiempos, pero durante años tuvimos que confiar en que la oficina de servicios lo haría bien. A pesar de lo baratas que son las pruebas ahora, incluso hoy en día solo les permite convertir el espacio de color en la cantidad de profesionales que trabajan.
¿Es posible utilizar un flujo de trabajo de código completamente abierto para el diseño de impresión?
RespuestasAquíPolítica de privacidad1y, 0v