[L3] Encoding di testo importato con \ior_str_map_inline

franen” post=88187Ho un file di testo di cui mi tornerebbe comodo potrer importare le singole righe come elementi di una \seq di LaTeX3 per poi poterle trattare con altri comandi. Mi si presentano due problemi:
– le righe di testo contengono comandi di LaTeX che non vengono poi espansi opportunamente;
– con pdflatex i caratteri accentati non risultano corretti (le codifiche di editor, file di testo, inputenc sono coerenti), mentre con xelatex funzionano.

Se creo la \seq inserendo manualmente il testo non ci sono problemi, quindi evidentemente il problema deriva da come [tt]ior_str_map_inline:[/tt] legge e scrive il testo (dalla documentazione: considera tutto con catcode 12 eccetto gli spazi). Interessante che anche le righe on i “%” inserite da filecontents vengano stampate.

Se al posto di [tt]ior_str_map_inline:[/tt] uso [tt]ior_map_inline:[/tt] non ho problemi né con la codifica né con l’espansione dei comandi, ma non ho più gli spazi. Vorrei evitare di avere un file di testo pieno di “~”.
Si può fare qualcosa?

Riporto un emc.

Fran
`\begin{filecontents}{prova.txt}
nàr: nèàòr re mo \emph{ciao}
Accà: È
Aàr: ggeèérr.
\end{filecontents}

\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{xparse}

\ExplSyntaxOn
\tl_new:N \l_line_temp_tl
\seq_new:N \g_all_lines_seq
\ior_new:N \g_DataBase %
\ior_open:Nn \g_DataBase {prova.txt}
\ior_str_map_inline:Nn \g_DataBase %oppure
%\ior_map_inline:Nn \g_DataBase
{
\tl_set:No \l_line_temp_tl { #1 }
\seq_put_right:No \g_all_lines_seq { \l_line_temp_tl }
}
\ior_close:N \g_DataBase

%\seq_show:N \g_all_lines_seq
\NewDocumentCommand{\stampa}{}
{
\seq_map_inline:Nn \g_all_lines_seq
{
##1\par\smallskip
}
}
% seq creata manualmente
\seq_set_split:Nnn \l_my_seq {|} {nàr:~ nèàòr~ re~ mo~ \emph{ciao} | Accà:~ È | Aàr:~ ggeèérr.}

\NewDocumentCommand{\stampab}{}
{
\seq_map_inline:Nn \l_my_seq
{
##1\par\smallskip
}
}
\ExplSyntaxOff
\begin{document}
\stampa

àèéìòù

\stampab
\end{document}`

La differenza fra [tt]\ior_str_map_inline:Nn[/tt] e [tt]\ior_map_inline:Nn[/tt] è proprio che la prima funzione legge una riga come stringa con tutti i caratteri di categoria 12 (eccetto gli spazi che rimangono di categoria 10, essenzialmente come fanno [tt]\detokenize[/tt] e [tt]\tl_to_str:n[/tt]). Il tuo errore è di usare [tt]\ior_map_inline:Nn[/tt] nell’ambiente di programmazione (cioè fra [tt]\ExplSyntaxOn[/tt] e [tt]\ExplSyntaxOff[/tt]).

Fai anche un bel po’ di giri inutili, a dire il vero. 😉

`\begin{filecontents}{\jobname.txt}
nàr: nèàòr re mo \emph{ciao}
Accà: È
Aàr: ggeèérr.
\end{filecontents}

\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{xparse}

\ExplSyntaxOn
\NewDocumentCommand{\carica}{m}
{
\franen_carica:n { #1 }
}
\seq_new:N \g_franen_all_lines_seq
\ior_new:N \g_franen_DataBase_ior
\cs_new_protected:Npn \franen_carica:n #1
{
\seq_gclear:N \g_franen_all_lines_seq % se non vuoi accumulare, altrimenti toglilo
\ior_open:Nn \g_franen_DataBase_ior {#1}
\ior_map_inline:Nn \g_franen_DataBase_ior
{
\seq_put_right:Nn \g_franen_all_lines_seq { ##1 }
}
\ior_close:N \g_franen_DataBase_ior
}

\NewDocumentCommand{\stampa}{}
{
\seq_map_inline:Nn \g_franen_all_lines_seq
{
##1\par\smallskip
}
}
% seq creata manualmente
\ExplSyntaxOff
\begin{document}
\carica{\jobname.txt}
\stampa

àèéìòù
\end{document}`

Ciao
Enrico

franen” post=88190Chiaro, grazie.
Fran

Il giro inutile a cui mi riferivo è
`\tl_set:No \l_line_temp_tl { #1 }
\seq_put_right:No \g_all_lines_seq { \l_line_temp_tl }`
La prima istruzione è scorretta perché non vuoi espandere il primo token dell’argomento; meglio sarebbe [tt]\tl_set:Nn[/tt]. La seconda andrebbe anche bene, ma
`\seq_put_right:NV \g_all_lines_seq \l_line_temp_tl`
andrebbe meglio. Con [tt]V[/tt] si ottiene il valore della variabile tra graffe. Ma è, come dicevo, un giro inutile:
`\seq_put_right:Nn \g_all_lines_seq { #1 }`
è molto più efficiente! Non trovi? 😉

Nel mio codice noterai che è
`\seq_put_right:Nn \g_all_lines_seq { ##1 }`
ma solo perché quel codice è all’interno di una definizione.

Ciao
Enrico