eeschema plot searchable pdf

Bug #1710454 reported by Yuan Mei
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
KiCad
Fix Released
Low
Unassigned

Bug Description

I noticed that with the latest nightly build,

kicad-20170812-040158.84f1c8e-c4osx.dmg

The plotted schematic pdf output is non-searchable, or none of the letters in it is selectable in any pdf viewer. All letters seem to be converted to strokes. However it was not the case just a couple of weeks ago using an older nightly build

kicad-20170722-032549.f042fcd-c4osx.dmg

It doesn't seem to be an OSX specific issue. Linux versions have the same change of behaviour.

What happened?

Being able to search and select letters in a schematic pdf is very important.

Tags: pdf
Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

I'm not sure the pdf files exported by kicad have every used typical fonts. AFAIK, we have always exported stroke fonts in both schematics and boards. We currently have no reasonably accurate method for converting our internal stroke font to a system font that we could use to export schematics to pdf files with strings. This may happen in the future once the new file formats are in place since the plan is to support system fonts.

Changed in kicad:
status: New → Triaged
importance: Undecided → Low
Revision history for this message
Yuan Mei (z9p) wrote :

I am not suggesting that the exported pdf files should have system fonts, embedded or otherwise. In fact, I very much like the strokes since they guarantee that the pdf will display/print correctly in any viewer. The feature I am requesting is that the exported pdf should be search-able, e.g. when one searches for a particularly component U1, a simple `Find' in a pdf viewer should lead the viewer to jump to where the text `U1' is, hence locating the component. It is a tremendously important feature when boards and schematics/layouts (in pdf) are shipped to end user. Mysteriously I did get search-able pdf exports in one of the nightly builds in the past few weeks but it went away.

On the implementation, regardless of how it is implemented currently, I would suggest that the current stroke fonts be kept as they are, while an additional pdf layer, Mode 3 "Neither fill nor stroke text (invisible)", be added to the exported pdf. In this way no font mapping is required for display purposes. As long as the ``invisible'' fonts are placed at correct locations that overlap with the strokes, the pdf will be correctly search-able and the text will be select-able and copy-able. OCR-ed pdf files commonly use this technique.

Revision history for this message
jean-pierre charras (jp-charras) wrote :

Commit 0999b5cb77c9a1b44e7e194071c2acb7e33ffb1d should work in PDF files.
(search texts are enabled in Eeschema and Pcbnew).

Please try it (especially with texts using non ASCII8 chars)

Revision history for this message
Yuan Mei (z9p) wrote :

I confirm that the search and select-copy of text in pdf works with this commit. In terms of non-ASCII8 chars, things like `Ångström' work correctly, Chinese characters don't.

Changed in kicad:
status: Triaged → Fix Committed
Changed in kicad:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.