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.
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."
Created attachment 89364 [details] [review] Bug 22572: Display multiple spaces in MARC view
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.
Should this be 'needs signoff'?
No, the fix needs to be confirmed, then apply to other places (regarding my last comment).
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.