Problemas a resolver pre-Add-On

[GusRiva]

Problemas con el Framework antes de pasar al modelo de Add-On

[x] 1. Cuando la codificación compleja de una palabra está puesta línea por línea, en modo Author visualizo espacios que no deberían verse

[x] 2. La expansión de una abreviatura me la visualiza entre paréntesis y no, como antes, en negrita

[x] 3. No funciona el mouseover para ver el original o la expansión (según se tenga organizado)

[x] 4. Elementos vacíos me los visualiza; eso produce que se vean s en los muchos sitios en los que hemos insertado signos de puntuación. No es grave, pero quedaría mejor sin verse (o viéndose sólo con el mouseover).

[x] 5. Faltaría una función de regularización. A diferencia de hasta ahora, que sólo necesitaba la de i/j, u/v y w/wu, ahora la vamos a necesitar para todo tipo de letras, por ejemplo para convertir en minúsculas las mayúsculas de inicio de verso.

[x] 6. Faltaría también una función de intervención editorial (<sic> / <corr>)

[x] 7. Desapareció en esta versión del framework la función de <note>: no se pueden introducir notas ni tampoco se visualizan las que están en el documento.

[x] 8. En cuanto a <sic> y <corr>, ni siquiera se visualizan los que están en el código.

[GusRiva]

Algunas aclaraciones y dudas:

1. A mí me funciona bien, creo
2. Es un feature, no un bug. Pienso usar paréntesis y negrita. Tener en cuenta que siempre habrá que usarlo seleccionado opciones en "Styles" ("nur Abbreviatur"/"nur Auflösung")
3. Arreglado!
4. Arreglado!
5. Estoy en ello.
6. Cómo debería ser esta función? Me imagino dos funciones sic -> corr y corr -> sic . En la primera uno escribe y selecciona la variante correcta y luego debe introducir la forma corregida. En la segunda lo contrario. O solo sic -> corr sería suficiente?
7. Está. Se llama "comment". Puedo cambiar el nombre mejor.
8. Esto es importante! Cómo deberían verse? Me imagino que sic debería verse cuando seleccionamos "nur Original" en Styles y corr con "nur regularisiert". Pero sic debería verse distinto de orig y corr distinto de reg. @v-millet

[v-millet]

1. Entonces a lo mejor es que hay algo que no tengo bien. Acaso lo tendré mal codificado? Te mando dos capturas de pantalla de un punto al azar, en modo Author y en modo Text (activando 'nur regularisiert' y 'nur Auflösung' en Styles):

En modo Author en las primeras palabras de los versos ves claramente los espacios impropios que se ven allí (contrastando el verso primero y tercero con el segundo, que no los tiene).

2. Vale.
3. Con <sic>–> <corr> sería suficiente. No estamos hablando de correcciones hechas por el copista (esas las etiquetamos con <subst>), sino de intervenciones del editor sobre el texto. Y ahí resulta muy poco habitual escribir primero la versión corregida; lo normal es trabajar sobre la transcripción, marcar la letra sobre la que se quiere intervenir e introducir la forma en que se quiere que aparezca.
4. Si, 'comment' está, pero eso es para dejar comentarios; yo me refería a la función <note>: Transcription note, editorial note, etc. En la versión anterior del framework estaba: se abría una ventana, te pedía tipo de nota y responsable y te abría una ventana para introducir el texto
5. Bueno, si quieres distinguir en la visualización según tipos, y si para <orig> – <reg> usas negrita, para las abreviaturas paréntesis, entonces para <sic> – ` casi no te queda nada más que usar un color, por ejemplo el rojo para que resalten. A lo mejor no quedaría mal usar un color también para las abreviaturas, en lugar de los paréntesis...

[v-millet]

9. Estoy viendo que habría que tener en cuenta también el tema de la puntuación. En fase transcripción se pone la puntuación con CMD+. o con la función del menú. Pero luego en fase edición esos signos se regularizan: los existentes se sustituyen por moderno o se suprimen y se añaden puntos, comas, comillas, etc. modernos. Para eso también estaría genial una función.

[GusRiva]

Hola Victor, En cuanto a 1: los espacios en blanco dentro de <w> que están afuera del <choice> son significativos. En lugar de esto:

<w>
    <hi>
        <choice>
            <orig>D</orig>
            <reg>d</reg>
        </choice>
    </hi>az</w>

Esto:

<w><hi><choice>
            <orig>D</orig>
            <reg>d</reg>
        </choice></hi>az</w>

En algún momento discutí esto con Jakub y yo era partidario de hacer que solo los espacios dentro de <c> fuesen válidos, incluso dentro las palabras. Nunca terminamos de definirlo, pero por si acaso es mejor mantener esta interpretación de los espacios en blanco que es la estándard. Espero que se entienda?

[GusRiva]

Punto 7, agregadas las notas.

[v-millet]

Hola Gustavo,

Esas modificaciones las introdujo Jakub en el proceso de migración, porque en los archivos que mandamos nosotros iba todo en una línea. Aunque alguna también la añadimos nosotros.

La pregunta es: por qué  y pueden ir en líneas distintas, pero no?

Uff, modificar eso me va a costar un montón de horas. A ver qué puedo hacer.

Gracias y un abrazo

Victor

De: GusRiva @.> Responder a: iwein-digital/oxygen-frameworks @.> Fecha: viernes, 18 de junio de 2021, 14:37 Para: iwein-digital/oxygen-frameworks @.> CC: Victor Millet @.>, Mention @.***> Asunto: Re: [iwein-digital/oxygen-frameworks] Problemas a resolver pre-Add-On (#33)

Hola Victor, En cuanto a 1: los espacios en blanco dentro de que están afuera del son significativos. En lugar de esto:

                        D             d             az

Esto:

            D             d         az

En algún momento discutí esto con Jakub y yo era partidario de hacer que solo los espacios dentro de fuesen válidos, incluso dentro las palabras. Nunca terminamos de definirlo, pero por si acaso es mejor mantener esta interpretación de los espacios en blanco que es la estándard. Espero que se entienda?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[v-millet]

P.D.: He hecho una prueba y, efectivamente, ahora se ve mucho mejor. Gracias!!

De: GusRiva @.> Responder a: iwein-digital/oxygen-frameworks @.> Fecha: viernes, 18 de junio de 2021, 14:37 Para: iwein-digital/oxygen-frameworks @.> CC: Victor Millet @.>, Mention @.***> Asunto: Re: [iwein-digital/oxygen-frameworks] Problemas a resolver pre-Add-On (#33)

Hola Victor, En cuanto a 1: los espacios en blanco dentro de que están afuera del son significativos. En lugar de esto:

                        D             d             az

Esto:

            D             d         az

En algún momento discutí esto con Jakub y yo era partidario de hacer que solo los espacios dentro de fuesen válidos, incluso dentro las palabras. Nunca terminamos de definirlo, pero por si acaso es mejor mantener esta interpretación de los espacios en blanco que es la estándard. Espero que se entienda?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[GusRiva]

Espera que lo confirmo con Jakub...

[GusRiva]

Parece que está bien con esos espacios, no hay problema para el procesamiento... pero para solucionar la visualización en el framework no prometo nada todavía...

[v-millet]

Da igual: prefiero tenerlo todo igualado y poner cada en una línea, da igual qué más código lleve adentro.

De: GusRiva @.> Responder a: iwein-digital/oxygen-frameworks @.> Fecha: viernes, 18 de junio de 2021, 16:17 Para: iwein-digital/oxygen-frameworks @.> CC: Victor Millet @.>, Mention @.***> Asunto: Re: [iwein-digital/oxygen-frameworks] Problemas a resolver pre-Add-On (#33)

Parece que está bien con esos espacios, no hay problema para el procesamiento... pero para solucionar la visualización en el framework no prometo nada todavía...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[GusRiva]

Hola @v-millet ,

Estoy probando si se puede encontrar y reemplazar con expresiones regulares. Con esto podés encontrar las <w> seguidas de espacio en blanco:

(<w[^>]*>)[^\wſ<]+

Para que te lo reemplace por el contenido sin los espacios, en reemplazar usás:

$1

Esta estructura sirve para cualquier elemento. Para choice:

(<choice[^>]+>)[^\wſ<]+

Encontré con esto también varios elementos <w> sin contenido, pero no sé si son solo los archivos que yo tengo que están desactualizados

[v-millet]

Gracias, Gustavo. Probé un archivo buscando y sustituyendo en modo y me fue muy bien. Probaré con tu fórmula con ER. De momento, la experiencia con poner cada <w> y cada<pc> y cada <metamark> y cada<c> en una línea me está gustando. No sólo porque la visualización en modo Author es muchísimo mejor, sino también porque incluso me resulta más clara en modo Text.

[v-millet]

Tu fórmula me come todos los ampersand de las entities, no sé por qué. No hubo problema, porque las restituí...