Bug 22572 - Garbled content of MARC control fields in MARC view
Summary: Garbled content of MARC control fields in MARC view
Status: Failed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-24 21:04 UTC by Michael Kuhn
Modified: 2020-05-23 11:50 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 22572: Display multiple spaces in MARC view (2.11 KB, patch)
2019-05-05 17:58 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Kuhn 2019-03-24 21:04:34 UTC
MARC control fields consist of a fix number of positions that can contain blanks. The "MARC view" in the Koha staff client and the Koha OPAC garbles the content of such fields when the field contains more than one consecutive blank - in this case more than one consecutive blank is automatically collapsed down by the webbrowser to just one. Additionally blanks may be trimmed at the end of the content of a field.

For example MARC 008 does and must consist of exactly 40 positions, thus a line like the following (as shown via webbrowser in the MARC view) is always wrong:

800422s1978 sz a 1 ger

In fact the correct content of MARC 008 would look like the following

800422s1978    sz        a     1   ger  

Or better visible, when using # instead of blanks:

800422s1978####sz########a#####1###ger##

Seemingly, this applies to all MARC control fields: 006 (fix length 18 positions), 007 (variable length of up to 23 positions), 008 (fix length of 40 positions).

In the database the content of these fields is correct.

Maybe before showing the blank character in the "MARC view" it should be coded as HTML entity   so the webbrowser doesn't collapse it. Also it may be a good idea to show the beginning and the end of such fields because otherwise (like in the above example) it is not visible that the field does contain two positions with blanks at the end.
Comment 1 Owen Leonard 2019-03-25 15:11:14 UTC
I'm thinking we could do something like this in the template:

[% subfiel.marc_value | replace(' ', ' ') | $raw %]

...which would convert spaces to   for ALL output of MARC data, on the assumption that it doesn't hurt to do so with fields which don't rely on character position.

I don't think there's a good way to change the style of the output of just those fields, since there's nothing in the framework which specifies that those tags are  "positionally defined."
Comment 2 Jonathan Druart 2019-05-05 17:58:11 UTC
Created attachment 89364 [details] [review]
Bug 22572: Display multiple spaces in MARC view
Comment 3 Jonathan Druart 2019-05-05 18:00:02 UTC
I think this patch is the way to go as it HTML filters *then* replace the space with  , making sure the value will be correctly escaped.

We certainly will need to apply this change to other places.
Comment 4 Katrin Fischer 2019-11-24 16:20:59 UTC
Should this be 'needs signoff'?
Comment 5 Jonathan Druart 2019-11-25 10:33:41 UTC
No, the fix needs to be confirmed, then apply to other places (regarding my last comment).
Comment 6 Katrin Fischer 2020-05-23 11:50:50 UTC
We don't know which fields this should apply to, but we know from the standard which 00x are position controlled. I believe this information is used in other places in our code too (slightly different for UNIMARC and MARC21). We could use this to only replace the spaces for the controlled fields to limit the range of this change. The   will mean that the content can no longer 'break' on spaces for display, so limiting the effect to where needed would be good I think.