Desigualdad de información.

[e ch n]

I'm debugging a document and removing everything that's not required, and when I check, using the "Find/Replace Font" window, the fonts used in the document appear to be 6, but when packaging, in the "Fonts" section, it says there are 18! When I select one of the ones I don't recognize and request its location in the document, it doesn't appear in the "Find/Replace Font" window, and if it doesn't appear, it can't show me where it "supposedly" is located in the document.

The only font I think I could possibly add to the registered ones would be the "Basic Paragraph" font, Minion Pro, but other than that... 18 fonts.... 

What could be happening, and how can I sort the Fonts window, the "Packaging" window, and the "Find/Replace Font" window so that their information matches?

Thanks. 

[Dave Creamer of IDEAS]

Any Adobe Illustrator graphics in the file?

[Robert at ID-Tasker]

Or PDFs. 

[e ch n]

Sí, hay vínculos, casi todos son imágenes, pero ciertamente hay unos textos, entre los que está la familia "Rochester Pro Regualar", lo que entiendo justificaría una de esas disparidades. 

Imagino que si quisiera evitar esa inclusión dentro del conteo en el Empaquetado, debería hacer curvas el texto de ese vínculo, y con ello se evitaría en el conteo, aunque si se queda, y está justificada su procedencia, pues creo no hay problema. 

Pero no ubico todas las demás... 

[Robert at ID-Tasker · Accepted solution]

@e ch n

As per the screenshot - 12x are embedded = are part of the linked files. 

Start duplicating links one-by-one to a new, blank document - and see which one will show in the Package dialog. 

[e ch n]

Gracias @Robert at ID-Tasker 

¿Esa duplicación de vínculos en un documento nuevo, cómo debería hacerla de modo correcto, a fin de no generar algún error en el proceso?

[Robert at ID-Tasker · Accepted solution]

@e ch n

Select linked object and copy&paste to a new, blank document - then check Package dialog.

If there is nothing "interesting" - press Ctrl+Z / Undo - so you don't have to constantly create new, blank documents - then copy&paste next object. 

[e ch n]

Gracias @Robert at ID-Tasker 

Tal cual lo indicaste, realicé el proceso según las intrucciones de tu mensaje inferior y sí, esas fuentes están incrustadas en el archivo vinculado de AI... pero... el tema es que el vínculo colocado en ID, no tiene esas fuentes en la imagen... así que supuse que estarían en una capa oculta en el archivo de AI, y así era.

De modo que volví a colocar el vínculo en ID, asegurandome de que la capa de texto estubiera apagada y repetí el ejercicio, pero ID sigue reportando que "ahí" están, aunque visualmente no se haya incluido esa capa, ID detecta que ese vínculo la contiene.

Entonces: para limpiar el reporte de fuentes fantasma, ¿hay alguna alternativa distinta a borrarlas del achivo de AI, o esa es la única?

Gracias.

Así aparece el reporte de un vínculo libre de fuentes fantasma.

Aquí aparecen las fuentes fantasma incrustadas en el vínculo, pero ID no puede ubicarlas porque no se generaron dentro de ID

Aquí el vínculo de AI donde se muestra una de las 6 familias, no visible porque la capa se ocultó

Al colocar el vínculo me aseguré de que las capas de texto no fueran visibles, pero de todos modos las detecta en el Reporte.

[Robert at ID-Tasker · Accepted solution]

@e ch n

If font is part of the ai / PDF file - it will become "part" of the INDD file.

[e ch n]

Gracias @Robert at ID-Tasker 

Entiendo, ha quedado claro. 

[James Gifford—NitroPress]

This may not be relevant, but I've had documents with 'phantom' fonts — most often, things like bolded versions of fonts without a BF face — that resist all efforts to search and replace and eliminate.

A cycle to IDML and reopen/save as INDD — the usual document purge/rebuild cycle — has helped in these cases.

[e ch n]

Gracias @James Gifford—NitroPress 

Qué bueno que al parecer no es algo relevante.

Yo quería hacer esa limpieza para tener un documento en orden, a fin de que en el reporte no apareciera información falsa que de la impresión al cliente y al impresor de errores en el documento.

Ese "ciclo" de guardar/abrir/guarda/abrir..., ¿debería realizarlo de alguna forma en particualr, por un número de veces?

[James Gifford—NitroPress]

It's a one-time thing, or at least very infrequent. Doing Save-As fairly often, at least once a day, will purge a lot of unneeded undo and other working data, though, and is a good idea.

Save-As every day or a little more often to "clean out" the file and create a working backup rotation; IDML to INDD whenever a file does odd things or has glitches.

[Robert at ID-Tasker]

@James Gifford—NitroPress

I'm pretty sure @e ch n is asking if this operation should be performed a few times - repeatedly - like when you have a lot of empty spaces and you're not using GREP but a "regular" Find&Change and replace 2x spaces into one - so in case there are more than 2x - you'll have to run this Find&Change multiple times.

[James Gifford—NitroPress]

Okay. Answered what I thought was being asked. But of course Find/Replace and GREP searches often have to be repeated to catch and correct all instances — such as double space to single space, without using fancy GREP variable-character wildcards.

It's always possible to craft a Find/Replace that will do a job in one pass, but sometimes just easier to repeat the action until all the changes are found and fixed.

(Assuming that's the other correct answer, here. 🙂 )

[e ch n]

@James Gifford—NitroPress @Robert at ID-Tasker 

Gracias, tendré en cuenta este proceso.