Copy & Paste

[andan1965]

När man manuellt matar in exempelvis en Text-Notis och trycker på Enter för radbyte, visas symbolen ¶ (paragraph sign).

Om man istället kopierar en text som innehåller radbyten, från t ex Anteckningar (Notepad), till en Text-Notis, läggs inte några ¶ till.

Se bifogad bild, där en Referens-Notis har kopierats från Anteckningar, och en Text-Notis har matats in manuellt.

Det verkar som om symbolen ¶ inte bara visas, utan faktiskt lagras i notisen. Det märks om man kopierar tillbaka till t ex Anteckningar, men framför allt märks det vid export till GEDCOM:

1 NOTE Överkalix kyrkoarkiv, Förhörsböcker:4 1814-1825 sid 1705 1825-1834 sid 2216 1835-1845 sid 1797 1845-1852 sid 133 och 204
2 CONC 8 1853-1860 sid 1619a 1861-1870 sid 17210a 1871-1880 sid 174
2 CONT
2 CONT
1 NOTE Test av text med manuellt
2 CONT
2 CONT inmatad radbrytning.
2 CONT
2 CONT

Vid export tas alla radbrytningstecken bort! Istället för "sid 170<radbyte>5" blir det "sid 1705".

Därimot ger ¶ en radbrytning (paragrafbrytning).

Jag vet inte detaljer i GEDCOM-formatet, men kanske borde Disgen exportera till:

1 NOTE Överkalix kyrkoarkiv, Förhörsböcker:
2 CONT 4 1814-1825 sid 170
2 CONT 5 1825-1834 sid 221
...osv

Eller åtminstone ersätta alla radbrytningar med mellanslag.

Eventuellt borde också ¶ läggas till när man klistrar in flera rader i en Notis.

Varför ¶ används ihuvudtaget är för mig en gåta, men det har kanske historiska orsaker...

[Christer]

Undrar du hur Anteckningar (Notepad) hanterar sina redigeringar, t.ex radbyte?

[andan1965]

Undrar du hur Anteckningar (Notepad) hanterar sina redigeringar, t.ex radbyte?

Nej, inte alls. Jag önskar att (framtida) Disgen hanterar radbrytningar bättre.

För mig är detta en bug/felaktighet i Disgen.

[andan1965]

Jag provar på nytt, och försöker förklara lite tydligare. Såg nu också att ¥ finns.

I en textnotis finns följande text inmatad:

Rad A¶
Rad B¥
Rad C
Rad D

När man gör en GEDCOM-export, kommer notisen att exporteras som:

1 NOTE Rad A
2 CONT
2 CONT Rad B
2 CONT Rad CRad D
2 CONT
2 CONT

Radbrytningen mellan "Rad C" och "Rad D" försvinner helt och ersätts inte med något annat. Något borde göras åt detta.

FÖRSLAG:

Om Disgen ska använda sig av egna "radbrytskommandon" som ¶ och ¥, så borde Disgen också göra:

1) Vid "klistra in text" så läggs ¥ till vid varje radbrytning, så när man kopierar och klistrar in från webbsidor, Sveriges dödbok, Anteckningar, Word, Excel, mm, behålls radbrytningarna.

2) Om inte ¶ eller ¥ finns vid en radbrytning, kan man inte bara slå ihop rader. T ex en webbläsare ersätter i sådant fall radbrytningen med mellanslag. Förslagsvis bör Disgen göra detta också.

3) När en "multirads" notis (fönster) visas i personöversikten, ska kanske inte ¶ och ¥ synas, utan texten ska formateras med de regler Disgen använder för ¶ och ¥, samt när inte ¶ eller ¥ finns.

4) Om man kopierar ifrån en notis till Anteckningar, Word, Excel, mm, så ska kanske en formatering göras. Åtminstone bör kanske ¥ tas bort.

Jag hinner inte skriva mer just nu, så ovanstående är kanske inte 100% genomtänkt.

[Christer]

Frågan sönderfaller i ett par tre olika delar.

Textredigering
När du skriver en text i textrutan i textnotisen så visas den löpande på det antal rader som krävs. Det är inga egentliga radbyten utan bara en anpassning av texten för att kunna visas i textrutan. Det är således anpassat till textrutans bredd. Jämför till exempel med olika ordbehandlare och deras marginaler. Denna uppdelning ignoreras av Disgen vid utskrifter eftersom den beror på hur brett fönstret är (en gång i tiden fick inga rader vara längre än 80 tecken).

Du kan naturligtvis skapa egna radbyten och stycken med hjälp av vagnretur (Enter resp Shift-Enter) för att t.ex. påverka utskriften. I Disgens text visas då olika tecken för att visa det.

För fotnoter och anteckningar hanteras det lite annorlunda.

Detta finns beskrivet (kanske inte så bra) på hjälpsidorna "Textnotiser" och "Radplanering vid utskrifter"

Klipp-och-klistra
Klipp och klistra av text till och från andra program fungerar för själva texten men all formatering blir oftast dålig eftersom de olika programmen inte kan tolka varandras formateringar, både de interna och de synliga, så bra. Det visade sig med all önskvärd tydlighet när ajg klistrade in GEDCOM-texten nedan.

GEDCOM
Saxat från standarden:
"Long values can be broken into shorter GEDCOM lines by using a subordinate CONC or CONT tag. The CONC tag assumes that the accompanying subordinate value is concatenated to the previous line value without saving the carriage return prior to the line terminator. The CONT assumes that the subordinate line value is concatenated to the previous line, saving the carriage return."

Begränsningar i radlängd tillsammans med både de radbrytningar som finns i redigeringsfönstret och de man själv gjort med Enter ger intressanta kombinationer av CONT och CONC och tomrader. Tanken här är troligen att textnotisen ska bli ungefär likadan om man exporterar och sen importerar igen till Disgen.

Slutsats
Allt ser så enkelt ut med "klipp och klistra" men verkligheten är mer komplicerad, det finns oftast formatering som måste hanteras i varje speciellt fall.

[C-J Gustafsson]

Om man ofta använder klipp & klistra från formaterade texter kan ett bra tips vara att klistra in texten i en ren texthanterare, t.ex. Notepad/Anteckningar. Därifrån gör man sen klipp & klistra till Disgens notis.

Det städar bort formateringstecken och lämnar bara formateringarna "radbrytning" och "nytt stycke", d.v.s. samma som Disgen och GEDCOM använder.

Formaterad text i en GEDCOM fil orsakar ofta att GEDCOM filen innehåller formella fel som gör att den inte accepteras för import. När en GEDCOM fil blir formellt felaktig är det till 99% orsakat av formaterade texter.

[andan1965]

Klipp och klistra av text till och från andra program fungerar för själva texten men all formatering blir oftast dålig eftersom de olika programmen inte kan tolka varandras formateringar, både de interna och de synliga, så bra.

Detta är inte sant.

Det jag pratar om är vanlig text-kopiering, det som i Word kallas "Behåll endast text" eller "Oformaterad (Unicode) text". Därför skrev jag bara om Anteckningar mitt första inlägg. Men bra Windows-program, som t ex Word, Excel, webbläsare, mm, lägger flera format i Urklipp vid kopiering, bland annat ett rent text format.

För programutvecklare, se t ex:

https://docs.microsoft.com/en-us/win...pboard-formats

CF_TEXT / CF_UNICODETEXT
(Unicode) text format. Each line ends with a carriage return/linefeed (CR-LF) combination. A null character signals the end of the data.

Disgen hanterar inte radbyten (carriage return/linefeed) på rätt sätt.

I Windows är CR-LF alltid ett radbyte!

Som det är nu blir CR-LF inget tecken alls vid GEDCOM-export, vilket ger rena fel vid exporten.

[andan1965]

Om man ofta använder klipp & klistra från formaterade texter kan ett bra tips vara att klistra in texten i en ren texthanterare, t.ex. Notepad/Anteckningar. Därifrån gör man sen klipp & klistra till Disgens notis.

Jajamän. Ett jättebra tips som jag använder hela tiden, och inte bara i Disgen utan i alla möjliga sammanhang.

Problemet är att infogar du inga ¥ (Shift+Enter) manuellt efter du klistrat in, så får du inga radbrytningar vid GEDCOM-export.

Så om du har i notisen:

Sid 12
3 bilder

Exporteras det till:

Sid 123 bilder

Vilket är hur dåligt som helst.

[C-J Gustafsson]

Rätt Anders, jag hade nog inte kollat så noga.

Sid 12
3 bilder

blev vid inklipp i Disgen
Sid 12 3 bilder

som vid GEDCOM export blev
Sid123 bilder

Men som Anders skriver, när man manuellt lägger in radbyte så blir det rätt
Sid 12
3 bilder

Disgen behöver göra någon justering, antingen att behålla löpande text och då justera GEDCOM exporten eller hantera CR-LF som radbrytning vid klistra in.

Det finns ju en poäng med det sätt som Disgen hanterar löpande text då det innebär att löpande text förblir löpande text även när det är olika radlängder på in-texter och ut-texter.

Bästa resultatet blir nog att det borttappade mellanslaget vid GEDCOM export fixas och att användaren med manuell radbrytning styr önskade radbyten.

[andan1965]

Jag förstår inte varför Disgen använder sig av egna påhittade "radbrytstecken" som ¶ och ¥.

Normalt använder de flesta "plain text" program/gränssnitt radbyte som just radbyte, och eventuellt två radbyten efter varandra som paragrafbyte. Vad jag förstår använder GEDCOM just den metoden med dubbla radbyten.

*OM* nu Disgen ska använda egna "radbrytstecken", *BÖR* Disgen omarbeta texten vid urklippsformaten CF_TEXT och CF_UNICODETEXT vid både "kopiera" och "klistra in", liksom alla andra Windows-program gör.

Funktionen bör vara sådan, att uppreppade kopiera och klistra in, fram och tillbaka, mellan Disgen och Anteckningar, inte ska förändra texten eller hur radbyten fungerar.

Det enklaste hade varit om Disgen behandlade CR-LF som ett vanligt radbyte, liksom alla andra. Jag förstår inte varför det inte är så, men det har kanske någon historisk orsak (bakåtkompatibilitet).

Hade Disgen varit mitt program, hade jag nog övervägt att i en ny release (version av databasen) ersätta alla sekvenser av "¥ CR LF" med "CR LF" och "¥ NUL" med "NUL", och sedan behandlat "CR LF" som radbyte. Vem har utnyttjat att Ctrl-Enter ger ett i Disgen synligt radbyte som vid export/presentation tas bort? I så fall borde man vända på det och låta "¥" betyda "bind ihop med nästa rad". Det hade varit mer naturligt.

Redigeringskommandon inom < och >, språkval efter $ och vilka andra koder som kan finnas, är en annan historia, de kan vara orörda som de är vid Copy & Paste. Jämför med hur man redigerar ett inlägg här i forumet.

(Jag har yrkesmässigt jobbat med programutveckling i ca 35 år inom DOS, Win16, Win32 och .NET).

[Christer]

Visst spelar arvet en stor roll. Men även vilka verktyg som utvecklingsmiljön erbjuder, vilket jag inte personligen har insikt i.

Jag har registrerat ditt förslag i vårt ärendehanteringssystem. Sen återstår att bedöma vilken arbetsinsats som krävs och vilken nytta ändringen tillför. I en värld med ideella krafter och begränsade resurser är prioriteringen minst lika viktigt som i den kommersiella.