20131001-missing-images-in-FI

<< | Index | >>

Summary

• FI do not display image
• Create dummy package when importing FI/PI
• Links in imported FI/PI should display correctly

Commits

• https://github.com/ngiger/oddb.org/commit/cd8f3a4210e2ae2468d7946e57395c4efa14963e Save x-wmf/x-emf files to display them correctly
• https://github.com/ngiger/oddb.org/commit/0d0f8b83f122a15711f38fe9788062939019d8e8 Fixe atcCode and packages if no dummies present
• https://github.com/ngiger/oddb.org/commit/530e286ceef5de0e45d1bc3dea247398643146cb Fix access to nil. Import newly found registrations

Index

• FI do not display image
• Create dummy package when importing FI/PI
• Links in imported FI/PI should display correctly
• import_daily must generate FI and PI for all newly created registrations

import_daily must generate FI and PI for all newly created registrations

import_daily calls (via import_swissmedicinfo) import_swissmedicinfo_by_index. Changed it to import at the end newly created registrations. Could not test it really, because the current AipsDownload_latest.xmll did not contain any new IKSNR.

See patch Fix access to nil. Import newly found registrations

Links in imported FI/PI should display correctly

An example found in 62438 Isoniazid USP, displays

Die entsprechenden Richtlinien können aus dem Internet heruntergeladen werden:
http://www.tbinfo.ch/index.aspx?PID=31.2.6.582.589.0.0.589.1.N.0.Y.0.0.0.0

But the display exactly the same way under swissmedicinfo.ch. And they are wrong, or must be selected manually. Should we change it here?

Create dummy package when importing FI/PI

We have at the moment a few registrations in the database which have a sequence, but not package. To clean it up, we must automatically create a dummy package (if there is none) while importing FI/PI from swissmedic-info.

Created new procedure create_dummy_package_if_necessary. Getting dump from thinpower to recreate situation. Testing with Xeljanz 62630.

Remarked that we need a dummy package AND the atc_classes to work correctly.

Rerunning the import of 63029 63030 62438 62785 62920 57515 33709 62566 67769 62658 62612 69870 29300 57487 62630 62786 58458 00828 17644 12498 10754 62470 42180 54371 31919 72736 62583 52265 with a database reloaded with yesterdays dump.

Great! It seems to work find. Can now find via trademark "Xeljanz" even before the whole import finishes!

Pushed commit Fixe atcCode and packages if no dummies present

After adding a new registration when parsing the AipsDownload we must be able to find it by name

After importing we don't see any image in 52810 "OctreoScan®". The problem is that we do not recognize x-emf as not handled image format. We do however flag x-wmf as not supported. Therefore I patch src/plugin/text_info.rb to flag all non-conforming types (not only x-wmf) in the import message.

Found the following possible transcoders:

• unoconv: Translates ODT documents with embedded *.emf|xmf to PDF-files (not verified, whether it really works)
• transfig: Could translate *.emf into *.tex files
• xnview: Proprietary SW. see http://www.xnview.com/de/xnview/

Zeno and I decided to use the display mechanisme of modern browser. Therefore the patch Save x-wmf/x-emf files to display them correctly should make our users happy. See